- 1 - 


RECEIVED 

JAN 0 9 2004 

Technology Center 2100 


VIRTUAL LOGICAL RESOURCE LINE REPLACEABLE UNIT FOR A PASSENGER 
ENTERTAINMENT SYSTEM, METHOD AND ARTICLE OF MANUFACTURE 


COPYRIGHT NOTIFICATION 


Portions of this patent application contain materials that are subject to copyright 
protection. The copyright owner has no objection to the facsimile reproduction by 
anyone of the patent document, or the patent disclosure, as it appears in the Patent 
and Trademark Office. 


RECEIVED 


FIELD OF THE INVENTION 


The present invention relates to providing entertainment to passengers in a vehicle, and 
more specifically, to systems, methods and articles of manufacture that provide for a 
networked passenger entertainment system that integrates audio, video, passenger 
information, product ordering and service processing, communications, and 
maintainability features, and permits passengers to selectively order or request 
products and services, receive video, audio and game data for entertainment purposes, 
and communicate with other passengers and computers on- and off-board the aircraft, 
and which thereby provides for passenger selected delivery of content over a 
communication network. 


BACKGROUND OF THE INVENTION 

The assignee of the present invention manufactures in-flight aircraft passenger 
entertainment systems. Such systems distribute audio and video material to 
passengers derived from a variety of sources. For example, such systems provide 
passengers with audio generated from audio tape players, movies derived from video 
tape players, and interactive services such as games, shopping and 
telecommunications. A variety of inventions have been patented by the assignee of the 
present invention and others relating to in-flight aircraft entertainment systems and 
their components. Certain of these prior art systems and components are summarized 
below. 

US Patent No. 3,795,771 entitled "Passenger Entertainment/ Passenger Service and 
Self-Test System" discloses a time multiplexed passenger entertainment and service 
combined system suitable for distribution throughout compartments of super aircraft. 
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Common power supplies, cabling, and boxes, and hybrid microelectronics and/or 
medium or large scale MOSFET integrated circuit chips are employed. A main 
multiplexer receives passenger address or tape deck analog signals and converts them 
to a pulse code modulated digital bit stream which is time shared between channels. A 
5 coaxial cable transmits the bit stream to compartment submultiplexers. Each 

submultiplexer receives the digital bit stream, optionally inserts into the bit stream bits 
representing analog-to-digital converted movie audio or compartment introduced 
passenger address and distributes the data stream along four columns of seat group 
units on individual column coaxial cables. At each seat group unit a demultiplexer of a 
10 seat group demultiplexer/ encoder converts the bit stream into the original analog 
signals, amplifiers the analog signals and drives individual seat transducers for 
passenger listening. 

A passenger control unit provides channel and volume level selection. The passenger 
service system provides control functions comprising reading light, stewardess call 
15 (aisle and control panel lights and chimes). The service system comprises a section 
timer/ decoder to generate binary logic pulses which are transmitted by cable 
sequentially down and up the seat columns from seat group unit to seat group unit. A 
similar cable connects the corresponding overhead unit containing the reading lights, 
etc. to the section timer/ decoder. The seat encoder of each seat group demultiplex- 
20 er/ encoder receives digital interrogating signals, processes them relative to switch posi- 

tions determined by the passenger and sends out results to the section timer/ decoder. 
The overhead decoder of each seat group receives the retransmitted digital signals from 
the section timer/ decoder and performs switching functions conforming to seat encoder 
commands. The system incorporates a self-test subsystem comprising a test signal 
25 generator and circuits operating in conjunction with the entertainment and service 
system circuits. 

US Patent No. 5,289,272 entitled "Combined Data, Audio and Video Distribution 
System in Passenger Aircraft" discloses a passenger aircraft video distribution system 
that distributes modulated RF carrier signals from a central signal source to be used at 
30 each passenger seat. The carriers are modulated to contain audio, video also other 

digital data, such as graphics, and slide shows and the like. Analog video signals from 
the video source are modulated on individually discrete carriers in the range of 54 to 
300 megahertz. Audio information, including audio sound channels and the video 
audio, are digitized and combined with digital data in a combined serial bit stream that 
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is multiplexed, and then modulated on an RF carrier having a frequency sufficiently 
above the frequency band of the video signals so that the resulting spectrum of the 
modulated audio RF carrier does not interfere with the modulated video carriers. The 
RF carrier signals are combined and distributed to individual seats. The modulated 
5 audio carrier is separated from the video carriers at each seat or each group of seats 
and then demodulated and demultiplexed for selection at each individual seat of a 
chosen audio channel. 

US Patent No. 4,866,515 entitled "Passenger Service and Entertainment System for 
Supplying Frequency-Multiplexed Video, Audio, and Television Game Software Signals 
10 to Passenger Seat Terminals" discloses a service and entertainment system for 

transmitting video signals, audio signals and television game software signals from a 
central transmitting apparatus to each of a plurality of terminals mounted at respective 
passenger seats in an aircraft, or at respective seats in a stadium, or theater, or the 
like. The video signals, audio signals and television game software signals are 
15 frequency-multiplexed and then transmitted to the terminals, so that desired ones of 
the frequency-multiplexed signals can be selected at each terminal unit. 

US Patent No. 4,647,980 entitled "Aircraft Passenger Television System" discloses a 
television system that provides for individualized program selection and viewing by 
aircraft passengers. The system comprises a plurality of compact television receivers 
20 mounted in front of each airline passenger in a rearwardly facing position within the 
passenger seat immediately in front of each passenger. Each television receiver is 
provided as a lightweight module adapted for rapid, removable installation into a 
mounting bracket opening rearwardly on the rear side of a passenger seat, with a 
viewing screen set at a tilt angle accommodating an average reclined position of the 
25 seat. Exposed controls permit channel and volume selection by the individual 

passenger, and an audio headset is provided for plug-in connection to the module. A 
broadcast station on the aircraft provides prerecorded and/or locally received programs 
on different channels to each television module for individual passenger selection. 

US Patent No. 4,630,821 entitled "Video Game Apparatus Integral with Aircraft 
30 Passenger Seat Tray" discloses a video game apparatus employed by a passenger of an 
aircraft. The apparatus includes a tray that is mounted on the rear of an aircraft seat. 
The tray has an internal hollow with a rectangular aperture on a top surface which 
surface faces the passenger when the tray is placed in a usable position. Located in the 
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rectangular aperture is a TV display screen. Located in the internal hollow of the tray 
is a video game apparatus that operates to provide a video game display on the surface 
of said TV display screen. The surface of the tray containing the TV display screen also 
includes a plurality of control elements that are coupled to the video game apparatus to 
5 enable the passenger to operate the game. To energize the game, the tray contains a 
cable coupling assembly whereby when a cable is inserted into the assembly, the video 
game is energized to provide a display of a game selected by means of a selector switch 
also mounted on the top surface of the tray. 

US Patent No. 4,352,200 entitled "Wireless Aircraft Passenger Audio Entertainment 
10 System" discloses that audio information in several audio channels is supplied via head 
sets to passengers seated aboard an aircraft in rows of seats including armrests and 
being distributed along an elongate passenger section inside a metallic fuselage. An 
antenna is run along the elongate passenger section of the aircraft for radio 
transmission inside such elongate passenger section. Individual antennas are provided 
15 for the passenger seats for receiving the latter radio transmission. These receiving 

antennas are distributed among predetermined armrests of the passenger seats. The 
audio information to be transmitted is provided in radio frequency channels in a band 
between 72 and 73 MHz. The distributed receiving antennas are coupled via seated 
passengers to the transmitting antenna. The radio frequency channels are transmitted 
20 in the mentioned band via the transmitting antenna, seated passengers and distributed 
receiving antennas to the predetermined armrests. Audio information is derived in the 
audio channels from the transmitted radio frequency channels also in the 
predetermined armrests. Passengers are individually enabled to select audio 
information from among the derived audio information in the audio channels. The 
25 selected audio information is applied individually to the headsets. 

US Patent Nos. 5,965,647 and 5,617,331 entitled "Integrated Video and Audio Signal 
Distribution System and Method for use on Commercial Aircraft and Other Vehicles" 
disclose passenger entertainment systems employing an improved digital audio signal 
distribution system and method for use on commercial aircraft and other vehicles. A 
30 plurality of digital audio signal sources are provided for generating a plurality of 

compressed digital audio signals. The compressed digital audio signals are provided to 
a multiplexer that domain multiplexes the signals to produce a single composite digital 
audio data signal. The composite digital audio data signal is provided to a 
demultiplexer which is capable of selecting a desired channel from the composite digital 
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audio data signal. The selected channel is provided to a decompression circuit, where it 
is expanded to produce a decompressed digital output signal. The decompressed digital 
output signal is then provided to a digital-to-analog converter and converted to an 
analog audio signal. The analog audio signal is provided to an audio transducer. 

5 While the above patents disclose various aspects of passenger entertainment systems 
and components used therein, none of these prior art references disclose a fully 
integrated networked passenger entertainment system that integrates audio, video, 
product ordering and service processing, networked communications, and 
maintainability features. Accordingly, it is an objective of the present invention to 
10 provide for systems and methods that implement an integrated networked passenger 
entertainment and communication system that provides for passenger selected delivery 
of content over a communication network. It is a further objective of the present 
invention to provide for systems and methods that permit passengers to selectively 
order or request products or services, receive audio, video and game data, that permits 
15 communication of information to passengers from aircraft personnel, and that permits 
passengers to communicate with other passengers and computers located on- and off- 
board an aircraft. 

SUMMARY OF THE INVENTION 

20 The foregoing problems are overcome in an illustrative embodiment of the invention in 
which a computer manages communication over a network between one or more 
network addressable units and a plurality of physical devices of a passenger 
entertainment system on a vehicle. The passenger entertainment system is configured 
and operated using software to provide passenger entertainment services including 
25 audio and video on-demand, information dissemination, product and service order 
processing, video teleconferencing and data communication services between 
passengers on-board the vehicle using a local networks, and between passengers and 
people and computers off-board the vehicle using a communications link. 

30 The passenger entertainment system includes a system server and a network for 

supporting a plurality of computer processors that are each coupled to a video camera, 
a microphone, a video display, an audio reproducing device, and an input device located 
proximal to a plurality of seats. The computer processors and the system server 
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comprise application software that selectively controls telephony applications and 
network services. The system server has a plurality of interfaces that interface to 
components (physical devices) of the passenger entertainment system. 

5 In carrying out the present invention, the system server is coupled by way of the 

network to a plurality of physical devices. The system server comprises software for 
instantiating a dispatch object to open a framework for one or more network 
addressable unit objects. The system server comprises software for instantiating one or 
more virtual line replaceable unit objects to manage communication between a network 
10 address unit and one or more physical devices. The system server comprises software 
for communicating network messages through the dispatch object to the one or more 
network addressable unit objects to the one or more physical devices to control one or 
more aspects of the passenger entertainment system. 

15 The dispatch object contains logic that tracks messages to the one or more physical 
devices utilizing a queue, logic that tracks messages from the one or more physical 
devices utilizing a queue, and logic that converts messages from a first format to a 
second format. The dispatch object maintains the status of related devices. The 
dispatch object also contains logic for adding and removing one or more of the network 
20 addressable unit objects. The network addressable unit objects include logic for moving 
data from one storage location to another. 


98-PS-039 



-7- 


BRIEF DESCRIPTION OF THE DRAWINGS 

The various features and advantages of the present invention may be more readily 
understood with reference to the following detailed description taken in conjunction 
with the accompanying drawings, and in which: 

Figure 1 illustrates an operational environment depicting a total entertainment system 
in accordance with a preferred embodiment; 

Figure 2 is an exemplary block diagram of an embodiment of the total entertainment 
system; 

Figure 3 shows a detailed block diagram of the total entertainment system of Figure 2; 

Figure 4 shows a diagram illustrating a typical hardware configuration of a workstation 
employed in accordance with a preferred embodiment; 

Figure 5 is a diagram illustrating head end equipment in accordance with a preferred 
embodiment; 

Figure 5a is a diagram illustrating distribution of QAM digital audio in accordance with 
in accordance with a preferred embodiment; 

Figure 6 is a block diagram of area distribution equipment in accordance with a 
preferred embodiment; 

Figur e 6a illu s trat e s d e tail s of an ar e a di s tribution box us e d in th e ar e a di s tribution 
e quipm e nt; 

Figure 7 is a block diagram of seat group equipment in accordance with a preferred 
embodiment; 

Figure 7a is a block diagram of the seat controller card of the seat group equipment in 
accordance with a preferred embodiment; 

Figure 7b is a block diagram of softwar e u se d in th e s e at controll e r card of Figur e 7a; 

Figur e 7c is a block diagram of an AVU int e rfac e to a parall e l t e l e phon e syst e m in 
accordanc e with a pr e f e rr e d e mbodim e nt; 
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Figur e 37 illu s trat e s T es t Port n e twork addr e ssabl e unit function and data paths; 

Figur e 38 illustrat es S e rvic e s function and data paths; 

Figur e 39 illu s trat e s - an e x e mplary cabin fil e-se rv e r databas e structur e ; 

Figur e 4 0 illustrat e s primary acc ess t e rminal n e twork addr e ssabl e unit function and 
data paths; 

Figur e 4 1 illustrat es primary acc es s t e rminal RPC cli e nt.DLL func t ion and data paths; 

Figur e 4 2a illu s trat es th e proc ess of cr e ating a CFS databas e on on e d e vic e and a CFS 
transaction log on anoth e r d e vic e ; and 

Figur e 4 2b illustrat e s th e process of installing and updating th e CFS databas e . 

Figure 9 is a block diagram of an Airplane Configuration System (ACS) tool used in 
accordance with a preferred embodiment; 

Figure 10 is a block diagram of the software architecture in accordance with a preferred 
embodiment: 

Figure 1 1 illustrates message processor function and data paths: 

Figure 12 illustrates operational flow of an ARCNET driver: 

Figure 13 illustrates primary access terminal network addressable unit function and 
data paths: 

Figure 14 illustrates transaction dispatcher function and data paths: 

Figure 15 illustrates system monitor function and data paths: 

Figure 16 illustrates primary access terminal RPC client.DLL function and data paths 
Figure 17 illustrates backbone network addressable unit function and data paths: 
Figure 18 illustrates seat network addressable unit function and data paths: 
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Figure 19 illustrates VCP network addressable unit function and data paths: 

Figure 20 illustrates Test Port network addressable unit function and data paths: and 
Figure 2 1 illustrates Services function and data paths. 

DETAILED DESCRIPTION 

R e f e rring now to th e drawing figur es . System Overview 

Figure 1 illustrates an operational environment depicting an exemplary total 
entertainment system 100 in accordance with a preferred embodiment. The 
operational environment shown in Figure 1 depicts a flight of an aircraft 111 employing 
the total entertainment system 100 . The total entertainment system 100 comprises an 
integrated networked passenger entertainment and communication system 100 that 
provides for in-flight passenger entertainment and information dissemination, service 
and product order processing, video teleconferencing and data communication between 
passengers on-board the aircraft 111, and video teleconferencing, voice and data 
communication between passengers 117 on-board the aircraft 111 and people and 
computers on the groundT 

Th e e x e mplary e mbodim e nt of the toted e nt e rtainm e nt syst e m 1 00 r es id es on th e 
aircraft m and compris es an int e grat e d n e twork e d pass e ng e r e nt e rtainm e nt and 
communication syst e m P S© that provid e s for in - flight pa sse ng e r e nt e rtainm e nt, 
information di s s e mination, vid e o t e l e conf e r e ncing and data communication b e tw ee n 
pa sse ng e rs on board th e aircraft 1M, and vid e o t e l e conf e r e ncing, voic e and data 
communication b e tw ee n pa s s e ng e rs on board th e aircraft 1 4-1- and p e opl e and 
comput e rs on th e ground. - Th e int e grat e d n e twork e d airborn e communication s yst e m 
p rovid es-e nt e rtainm e nt se rvic es ^ information distribution, product and se rvic e ord e r 
proc ess ing, and communication s e rvic e s using local networks and the Internet 113 . 

The present invention thus provides for a level of capabilities and services heretofore 
unavailable in any airborne passenger entertainment system. 

Num e rous improv e m e nt s ov e r th e pr e d e c e s s or APAX - 150 s y s t e m d e v e lop e d - by - t - h e 
a ss ign ee of th e pr ese nt - inv e ntion and oth e r - prior art syst e m ar e incorporat e d in th e 
s y s t e m 1 00 . Th e s e ar e di s cu sse d in d e tail b e low, and ^ r e pr e s e ntativ e drawing s ar e 
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provid e d wh e r e appropriat e to s how d e tails n e c es sary to und e r s tand th e se 
improv e m e nts. 


5 


10 


15 


The system 100 is comprised of four main functional areas including head end 
equipment 200 , area distribution equipment 210 , seat group equipment 220 , and 
overhead equipment 230. The head end equipment 200 provides an interface to 
external hardware and operators. The area distribution equipment 2 10 routes signals 
to and/or from the head end equipment 200 , the seat group equipment 220 , and the 
overhead equipment 230, depending upon the type of service provided to or requested 
by the passengers. The seat group equipment 220 contains passenger control units 
(PCU) 121 and screen displays 122 , or di s play unit (DU) 122_ for use by the passengers 
117. The overhead equipment 230 includes video monitors and/or projectors and 
bulkhead screens or displays (Figur e 8) for displaying movies and other information. 
The system 100 thus routes or otherwise displays information to the passengers either 
under control of the flight attendants or passengers 117. Th ese functional ar e as and 
compon e nt s will b e d e scrib e d in mor e d e tail b e low. 


Video conferencing data and computer data derived from ground based computers 112 
connected to the Internet 113 is- are transferred over the Internet 113 to a satellite 
ground station 114 and is -are uplinked to a communications satellite 115 orbiting the 
Earth. The communications satellite 115 downlinks the video conferencing and/or 
20 computer data to the aircraft 111 which is received by way of an antenna 116 that is 
| part of a satellite communications system (Figur e 3) employed in the head end 
equipment 200 of the system 100. In a similar manner, video conferencing data 
and/or computer data derived from passengers 117 on-board the aircraft 111 is 
uplinked to the satellite 115 by way of the satellite communications system and 
25 antenna 116 to the satellite 115, and from there is downlinked by way of the satellite 
ground station 114 and Internet 113 to the ground based computer 112. 


30 


One or more satellites 115, which may be the same as or different from the satellites 
115 used for Internet communication, transmit television signals to the aircraft 111. 
One currently deployed satellite television broadcast system is the DIRECTV system 
that has orbiting satellites 115 that may be used to transmit television programs to the 
aircraft 111, in a manner similar to ground-based systems used in homes and 
businesses. In the present system 100. however, a steerable antenna 116 is used to 
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track the position of the satellite 115 that transmits the signals so that the antenna 
116 remains locked onto the transmitted signal. 

Handheld or fixed passenger control units 121 (Figur e 7d) and seatback screen displays 
122 (seat displays 122) are provided at each passenger seat 123 that permit the 
passengers 117 to interface to the system 100. The passenger control units 121 are 
used to control downloading of movies for viewing, select audio channels for listening, 
initiate service calls to flight attendants, order products and services, and control 
lighting. The passenger control units 121 are also used to control game programs that 
are downloaded and played at the passenger seat 123. In addition, the passenger 
control units 121 are also used to initiate video conferencing and computer data 
transfer sessions either within the aircraft or with ground based computers 112. 

The pa s s e ng e r control unit s 121 u ses carbon contact s in li e u of conv e ntional 
m e mbran e switch e s. This provid es for mor e - r e liabl e op e ration 

On e or mor e sat e llit es 3 45 , which may b e th e sam e a s or diff e r e nt from th e sat e llit e s 
446 u se d for Int e rn e t communication, tran s mit t e l e vision signals to th e aircraft 4 44r 
On e curr e ntly d e ploy e d sat e llit e t e l e vi s ion broadca s t s y s t e m is th e Dir e cTV syst e m 
which ha s orbiting sat e llit e s 1 46 that may b e u se d to tran s mit t e l e vi s ion programs to 
t h e- aircraft 3 4 4, in a mann e r similar to ground bas e d s yst e m s us e d in - hom es and 
bu s in e s se s. In th e pr ese nt syst e m 1 00 , how e v e r, a st ee rabl e ant e nna 1 46 is u se d to 
track th e po s ition - of - th e sat e llit e 1 45 that - transmits th e signal s so that th e ant e nna 
446 r e main s lock e d onto th e tran s mitt e d s ignal. 

The-present system 100 thus provides for an integrated and networked passenger 
entertainment and communication system 100 that in essence functions as an airborne 
intranet that provides a level of passenger selected and controlled entertainment and 
communications services, passenger services and product ordering services that has 
heretofore not been provided to aircraft passengers. Compl e t e d e tails of th e 
archit e ctur e of th e s y s t e m 1 60 and th e softwar e archit e ctur e e mploy e d in th e syst e m 
400 ar e d e scrib e d b e low. 

Figure 2 is an exemplary block diagram of an embodiment of a total entertainment 
system 100 that is employed on the aircraft 111, and illustrates inputs, outputs and 
interfaces of the system 100. The system 100 comprises the head end equipment 200, 
the area distribution equipment 210, the seat group equipment 220, and the overhead 


98-PS-039 




equipment 230. The head end equipment 200 and the seat group equipment 220 
include a variety of computer processors and operating software that that-communicate 
over various networks to control and distribute data throughout the aircraft 111 and 
send data to and receive data from sources external to the aircraft 111. A detailed 
5 embodiment of the total entertainment system 100 is shown in Figure 3, which will be 
described after discussing a representative hardware environment that is useful in 
understanding the system 100 and its operation which that is presented in Figure 4. 

A- pr e f e rr e dA n embodiment of the system 100 is practiced in the context of a personal 
computer such as the IBM PS/2, Appl e Macinto 6 h A PPLE MACINTOSH computer or 
10 UNIX based workstation. A representative hardware environment is depicted in Figure 
4, which illustrates a typical hardware configuration of a workstation in accordance 
with a preferred embodiment having a central processing unit 310 . such as a 
microprocessor, and a number of other units interconnected via a system bus 312 . The 
workstation shown in Figure 4 includes a random access memory (RAM) 314. read only 
15 memory (ROM) 316 . an I/O adapter 318 for connecting peripheral devices such as disk 
storage units 320 to the bus 312 . a user interface adapter 322 for connecting a 
keyboard 324. a mouse 326 . a speaker 328 . a microphone 332 . and/or other user 
interface devices such as a touch screen (not shown) to the bus 312 . communication 
adapter 334 for connecting the workstation to a communication network (e.g., a data 
20 processing network) and a display adapter 336 for connecting the bus 312 to a display 
device 338 . The workstation typically has resident thereon an operating system such 
as the Microsoft Windows MICROSOFT WINDOWS NT or Window s W INDOWS/ 95 
operating system (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating 
system. Those skilled in the art will appreciate that the present invention may also be 
25 implemented on platforms and operating systems other than those mentioned. 


R e f e rring to Figur e 3, th e h e ad e nd e quipm e nt 2 00 compris e s a m e dia se rv e r 211 in 

Detailed System Description 


30 


The in-flight entertainment system 100 in accordance with a preferred embodiment is a 
complex system with many components and that forms a total entertainment system 
(TES) 100. To assist the reader in making and utilizing the invention without undue 
experimentation, the following is a detailed description that discusses some of the 
components and a typical system configuration. The system 100 in accordance with a 
preferred embodiment that i s coupl e d to a first vid e o mndnlntnr 212a. Th a m e rlin 
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se rv e r 314 may b e on e manufactur e d by Formation, for e xampl e . Th e m e dia s e rv e r 
34 4 s uppli e s 30 ind e p e nd e nt s tr e ams of vid e o, and stor e s about 5 4 hour s worth of 
vid e o. Th e fir st- vid e o modulator 312a may b e on e manufactur e d by Ols e n 
T e chnologi es , for e xampl e . A vid e o r e produc e r 337 (or - ^id e o cass e tt e play e r 227), s uch 
5 a tripl e d e ck play e r manufactur e d by TEAC, for e xampl e , i s also coupl e d - to th e fir s t 
vid e o modulator 312a. Th e vid e o ca sse tt e play e r 327 is a configurable and scaleable 
in-flight entertainment system 100 that provides a wide range of passenger 
entertainment, communications, passenger service, and cabin management services. A 
fully capable system 100 provides passengers with audio entertainment, video 
10 entertainment, video games, and other interactive and communications services. 

The system 100 shown in Figure 1 and 2 has thr ee 8 mm Hi - 8 vid e o ca s sett e play e r s 
that output thr ee vid e o programs on thre e video chann e l s und e r control of a flight 
att e ndant. 


15 


Th e head e nd e quipm e nt 3 00 also compris e s on e or more landscap e cam e ra s 21 3 and a 
pa s s e ng e r vid e o information s y s t e m 2 1 3 that ar e coupl e d to a s e cond vid e o modulator 
Mflb . Th e landscap e cam e ra s 21 3- may b e cam e ra s manufactur e d by S e xton, or 
Puritan B e nn e tt, for e xampl e . Th e se cond vid e o modulator 31 3b may al s o b e on e 
manufactur e d by Ols e n T e chnologi e s, for e xampl e . Th e pas se ng e r vid e o informa tion 
s y s t e m 214 may b e a unit manufactur e d by Airshow, for e xampl e . 


20 


25 


30 


Th e h e ad e nd e quipm e nt 2 00 compri ses first and se cond pa s s e ng e r e nt e rtainm e nt 
s y s t e m controll e r s (PESC - A, PESG - V) 224a, 224 b , that compri se vid e o, audio and 
p hon e proc ess or s . Although only on e unit i s s hown, in c e rtain configuration, primary 
and se condary PESC A controll e r s 234 1 a may b e us e d. Th e s e cond vid e o modulat o r 
rout e s RF s ignals through th e first vid e o modulator 313a, and - th e output s of 
both vid e o modulator s 213a, 312b ar e rout e d through th e s e cond pass e ng e r 
e nt e rtainm e nt s y s t e m controll e r (PESC - V) 224 fc- to th e first pa s s e ng e r e nt e rtainm e nt 
sy s t e m controll e r (PESC - A) 224a. Th e fir s t pass e ng e r e nt e rtainm e nt s y s t e m controll e r 
( PES€ - A) - 224a i s u se d to di s tribut e vid e o and data by way of an RF cabl e 21 5 and an 
ARCNET - (RS -4 8 5) n e twork 21 4a (ARCNET 1; ARCNET 2), r e sp e ctiv e ly, to ar e a 
di s tribution four main functional areas comprising: 1) head end equipment 200, 2) area 
distribution equipment 210, 3) seat group equipment 220, and 4) overhead equipment 
31-3 which rout es th e vid e o and data to th e pass e ng e r seats 123 t 23Q. Figure 3 shows 
the four functional areas and the line replaceable units (LRU) that comprise a typical 
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passenger entertainment system 100. An overview of the LRUs in each of the 
functional areas is described in the following paragraphs. 


5 


The head end equipment 200 is the prime interface between external hardware and 
operators (purser and flight attendants). The head end equipment 200 includes an 
operator interface, an aircraft interface, a maintenance interface, and an interface for 
downloading configuration data to the system 100 and for downloading reports from 
the system. 


10 


15 


20 


The head end equipment 200 shown in Figure 3 comprises a primary access terminal 
(PAT) 225 and a cabin file server (CFS) 268 which that are used to control the system 
100. The cabin file server 268 is a system controller that controls many of the system 
functions, such as interactive functions, and stores the system 400 . Th e fir s t 
pa sse ng e r e nt e rtainm e nt s yst e m controll e r (PESC - A) 224a is coupl e d to th e cabin fil e 
se rv e r 2 68 by way of th e ARCNET n e twork (ARCNET 1) 21 6 , and is coupl e d to - th e 
primary acc ess t e rminal (PAT) 225 and th e s e cond pa s s e ng e r e nt e rtainm e nt s yst e m 
controll e r (P - ESC - V) 224 b by way of th e ARCNET n e twork (ARCNET 2) 21 6 . Th e first 
pa sse ng e r e nt e rtainm e nt s yst e m controll e r (PESC - A) 224a is also coupl e d to a public 
addr e ss (PA) - sy s t e m 222, to an audio tap e r e produc e r (ATR) 323, and to a cabin 
t e l e phon e s y s t e m (CTS) 23 0 . Th e audio tap e r e produc e r 223 may b e on e manufactur e d 
by Sony or Matsu s hita, for e xampl e . Th e cabin t e l e phon e syst e m 23 0 may b e s y s t e m s 
manufactur e d by AT&T or GTE, for e xampl e . Signals a ss ociat e d - with th e cabin 
t e l e phon e s y s t e m 23 $ ar -e- rout e d - through - th e s yst e m 1 00 by m e an s of a CEPT - E1 
net-work 2 W h 


Th e cabin fil e s e rv e r 2 6 8 i s coupl e d to th e primar y 1 acc ess t e rminal 225 and to a print e r 
226 by way of an Eth e rn e t n e twork 228, s uch as a 100 Ba se- T Eth e rn e t n e twork 228 t 
25 for e xampl e configuration database and the application software. The cabin file server 
268 communicates with other components within the head end equipment 200 via an 
ARCNET interface 216 . The cabin file server 268 is us e d to control th e storag e of 
cont e nt and us e information. Th e primary acc e ss t e rmin a l 225 i s u se d to control 
e nt e rtainm e nt f e atur e s and availability. Th e may be a computer terminal as shown in 
30 Figure 4 that includes a hard disk drive and a database that stores the system 100 
configuration and other system 100 information. 
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The cabin file server 268 is coupled to the primary access terminal 225 and to a printer 
226 by wav of an Ethernet network 228. such as a 100 Base-T Ethernet network, for 
example. Flight attendant workstations 225a are also coupled to the cabin file server 
268 bv wav of the Ethernet network 228. A media file server 211 is controlled from the 
cabin file server 268 by way of an ARINC 485 (RS-485) network 229 coupled 
therebetween. The cabin file server 268 is optionally coupled to a BIT/ BITE tester 
350221. that is used to perform built in testing operations on the system 100 . 


10 


15 


20 


25 


The vid e o r e produc e r 237 (or vid e o cas se tt e play e r 237) outputs a first plurality of 
NTSC vid e o (and audio) s tr e am s corr e sponding to a fir s t plurality of pr e record e d vid e o 
chann e l s . Th e m e dia s e rv e r 2 M stor e s and outputs a plurality of quadratur e 
amplitud e modulat e d MPEG - compr e ss e d vid e o transport str e am s corr es ponding to a 
se cond plurality of pr e r e cord e d vid e o chann e ls. Th e fir s t vid e o modulator 212a 
modulat es both th e NTSC vid e o s tr e am s from th e vid e o r e produc e r 337 and th e 
quadratur e amplitud e modulat e d MPEG - compr esse d vid e o s tr e ams from th e m e dia 
s e rv e r 2 1 1 to produc e modulat e d RF s ignals that ar e di s tribut e d to pa sse ng e r se at s 
43 3 - of fil e aircraft 111. Th e modulat e d RF s ignal s containing th e modulat e d vide e 
st r e am s- output by th e first vid e o modulator 212a ar e coupl e d through th e see ead 
pa sse ng e r e nt e rtainment sy s t e m controll e r 22 4b to th e first pa sse ng e r e nt e rtainm e nt 
s yst e m controll e r 334a and from th e r e by way of an RF cabl e 3 IS - to audio - video s e at 
di s tribution units (AVU) 281 locat e d at e ach pas se ng e r cabin file server 268 provides 
the following functions: processes and stores transaction information from passengers: 
stores passenger usage statistics for movies, games, and shopping: stores passenger 
survey responses: stores flight attendant usage statistics for login /logout: provides 
flight attendant access control: controls the video reproducers: controls the landscape 
camera: controls the PVIS line replaceable unit: stores seat 422r 


30 


Th e first - pa 6 s e ng e r e nt e rtainm e nt s y s t e m controll e r 22 4 a is coupl e d to a plurality of 
ar e a distribution box es 217 - by - way of th e RF cabl e 315 and th e ARCNET n e twork 21 6 t 
T h e ar e a di s tribution box e s 2 17 ar e us e d to distribut e digital and analog vid e o s tr e am s 
to th e audio - vid e o application software and game software: distributes seat distribution 
unit s 281 at th e pass e ng e r s e ats 123. Th e ar e a distribution - box es- 217 coupl e 
quadratur e amplitud e modulat e d MPEG - e e mpr esse d vid e o transport s tr e ams d e riv e d 
from - th e m e dia se rv e r 2 H - and NTSC vid e o signal s d e riv e d from th e vid e o ca sse tt e 
play e r 337 that hav e b ee n modulat e d by th e vid e o modulator 142 to th e pas se ng e r 
se at s 123 of th e aircraft 1 4-t rapplication and game software via the RF distribution 
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system: provides power backup sufficient to allow orderly automatic shutdown of the 
cabin file server 268 operating system when primary power is removed: provides 
indicators representing power, operational status, and communication status: 
downloads databases via the RF distribution system: provides the ability to print 
reports: and provides connectors for a keyboard, monitor, and mouse. 


10 


15 


20 


On e audio - vid e o se at di s tribution unit 231 is provid e d for -e ach s e at 133 and contain s-a 
tun e r and r e lat e d circuitry (T he primary access terminal 225 shown in Figure 7) that 
d e modulates th e modulat e d RF signal s , d e modulat e s th e NTSC vid e o s tr e am s to 
produc e Iff SC vid e o and audio s ignals for 3 provides an operator interface to the 
system 100. enabling an operator to centrally control a video reproducer 227 and the 
media server 211. start BITE, control the landscape cameras 213. and other functions 
provided in the system 100. The primary access terminal 225 may also be a computer 
terminal as shown in Figure 2 that may include a hard disk drive and a display 338 for 
graphical user interface (GUI1 bv a flight attendant to the system 100. The displavr-and 
d e compr es s es and - d e modulat e s th e quadratur e amplitud e modulat e d MPEG - 
compr e ss e d vid e o transport 6 tr e am 6 to produc e- MFEG NTSC vid e o and audio signal s for 
may be a touch screen displa y. Th e audio - vid e o s e at di s tribution unit 334 controls 
distribution of vid e o, audio and data to a h e ad se t 333 or h e adphon e s 333 . access the 
s e at di s play 133, and th e pass e ng e r control unit 131. - Th e audio - vid e o s e at 
di s tribution unit 231 coupl e s th e vid e o - and audio signal s- from - a -se l e ct e d vid e o str e am 
to -t he -se at di s play 123 and by way of a h e ads e t jack 1 3 2a to th e h e ads e t 1 33 
(h e adphon es 1 3 2) for pass e ng e r vi e wing and list e ning. 


25 


Th e pass e ng e r control unit 121 includ es an att e ndant cedi s witch 131a, a light switch 
131fe , and may includ e a t e l e phon e 13 lo and magn e tic card r e ad e r 1 3 1 4r 4 n - c e rtain 
zon e s of th e aircraft 1 4 1, a p e rsonal vid e o play e r (PVP) 138 i s coupl e d to th e audio - 
vid e o se at distribution unit 231 by way of a p e rsonal vid e o play e r int e rfac e 128a. Th e 
audio - vid e o s e at distribution unit - 231 provid e s an int e rfac e b e tw ee n th e t e l e phon e 
121 - 0 and th e cabin t e l e phon e system 339 - and p e rmits t e l e phon e call s to b e mad e by 
th e pass e ng e r 117 from th e se at 133 r 


30 


In c e rtain zon e s of th e aircraft 1 4 4, a p er sonal comput e r int e rfac e 139a is provid e d 
which allows th e pass e ng e r 1 17 to pow e r - a-p e rsonal comput e r 100. A keyboard (not 
shown) and to int e rfac e to th e syst e m 1 09 . — Alt e rnativ e ly, a k e yboard 139 1b may b e 
provid e d - that - allews th e pas se ng e r 117 to int e rfac e to th e -s yst e m 1 90 . Th e- u se of th e 
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p e r s onal - comput e r 129a - or k e ybo a rd - 1 2 ®h - provid es a m e an s for uploading and 
downloading - data by way of th e s at e llit e communication s s y s t e m 2 4 1 and th e Int e rn e t. 
In addition^ - a vid e o cam e ra is provid e d in th e adjac e nt to th e s e at display 132 that 
vi e w s th e- pa sse ng e r 117 to p e rmit vid e o t e l e conf e r e ncing - s e rvic es . D e tail s of th e audio 
vid e o unit 334 - will b e d e scrib e d in mor e d e tail with r e f e r e nc e to Figur e 7. may also be 
provided to access the system 100. The primary access terminal 225 is used to 
configure the system 100 to set up the entertainment options that are available to 
passengers 117. The flight attendant workstations 225a are distributed throughout 
the aircraft 111 and allow flight attendants to respond to passenger service requests 
and to process orders and monetary transactions. 

R e f e rring now to T he primary access terminal 225 provides the following functions: a 
flight attendant interface to the cabin sales capability, a flight attendant interface to the 
video entertainment capability, a flight attendant interface to the report and receipt 
printing capability, monitoring of video and audio output from the video reproducer, 
maintenance personnel interface to system diagnostics and status reports, power 
backup sufficient to allow an orderly shutdown of the primary access terminal 
operating system when primary power is removed, indicators representing power, 
operational status, and communication status, single and dual plug stereo audio jack, 
magnetic card reader, and floppy disk drive. 

The head end equipment 200 comprises the media server 211 that is coupled to a first 
video modulator 212a. The media server 211 may be one manufactured by Formation, 
for example. The media server 211 supplies 30 independent streams of video, and 
stores about 54 hour of video. The first video modulator 212a may be one 
manufactured by Olsen Technologies, for example. The video reproducer 227 (or video 
cassette player 227K such as a triple deck player manufactured by TEAC, for example, 
is also coupled to the first video modulator 212a. The video cassette player 227 may be 
three 8-mm Hi-8 video cassette players that output three video programs on three video 
channels under control of a flight attendant. 

The video reproducer 227 (or video cassette player 227) outputs an NTSC video (and 
audio) streams corresponding to a first plurality of prerecorded video channels. The 
media server 211 stores and outputs a plurality of quadrature amplitude modulated 
MPEG-compressed video transport streams corresponding to a second plurality of 
prerecorded video channels. The first video modulator 212a modulates both the NTSC 
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video streams from the video reproducer 227 and the quadrature amplitude modulated 
MPEG-compressed video streams from the media server 211 to produce modulated RF 
signals that are distributed to passenger seats 123 of the aircraft 111. 


5 


The head end equipment 200 also comprises one or more landscape cameras 213 and a 
passenger video information system (PVIS1 214 that are coupled to a second video 
modulator 212b. The landscape cameras 213 may be cameras manufactured bv 
Sexton, or Puritan Bennett, for example. The second video modulator 212b may also be 
one manufactured bv Olsen Technologies, for example. The passenger video information 
system 214 may be a unit manufactured bv AIRSHOW. for example. 


10 The head end equipment 200 comprises first and second passenger entertainment 
system controllers fPESC-A. PESC-V) 224a. 224b. that comprise video, audio and 
telephone processors. Although only one unit is shown in Figure 4 , it shows a 
s implifi e d diagram of th e sy s t e m 1 00 and illustrat e s di s tribution of vid e o s ignal s from 
th e vid e o ca sse tt e play e r 237 and m e dia se rv e r 311 to th e se at di sp lay s 133. To 
15 impl e m e nt vid e o on d e mand in accordanc e with a pr e f e rr e d e mbodim e nt, th e m e dia 

se rv e r 211 output s 30 digital MPEG - compr e ss e d vid e o transport str e ams on thr ee vid e o 
chann e ls (t e n str e am s e ach), whil e th e vid e o ca sse tt e play e r 337 outputs thr ee vid e o 
str e ams on thr ee vid e o chann e ls. 


20 


25 


30 


To gain -e xtra throughput, th e 30 digital MPEG compr es s e d vid e o str e ams output by th e 
m e dia s e rv e r - 3 M ar e 6 4- valu e quadratur e amplitud e modulat e d (QAM^ How e v e r, it is 
to b e und e r s tood, how e v e r, that by using 256 - valu e QAM e ncoding, for e xampl e , the 
numb e r of vid e o programs d e liv e r e d in e ach vid e o chann e l may b e furth e r incr e a se d. 
Cons e qu e ntly, th e pr ese nt sy s t e m H MD is not limit e d to any sp e cific QAM e ncoding 
value rS. in certain configurations, primary and secondary PESC-A controllers 224a may 
be used. The second video modulator 212b routes RF signals through the first video 
modulator 212a. and the outputs of both video modulators 212a. 212b are routed 
through the second passenger entertainment system controller (PESC-VI 224b to the 
first passenger entertainment system controller fPESC-Al 224a. The first passenger 
entertainment system controller (PESC-AI 224a is used to distribute video and data bv 
wav of an RF cable 215 and an ARCNET network 216. to area distribution equipment 
210 that routes the video and data to the passenger seats 123. The ARCNET network 
216 is used to send control signals between components of the head end equipment 
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and the components of the seat group equipment 220, The PESC-A 224a also provides 
an interface to the overhead equipment 230, 

The first passenger entertainment system controller (PESC-A! 224a is coupled to the 
cabin file server 268 by wav of the ARCNET network 216. and is coupled to the primary 
5 access terminal (PAT) 225 and the second passenger entertainment system controller 
(PESC-V1 224b by wav of the ARCNET network 216. The first passenger entertainment 
system controller (PESC-A) 224a is also coupled to a public address (PA) system 222. to 
an audio tape reproducer (ATR) 223, and to a cabin telephone system (CTS) 239. The 
audio tape reproducer 223 may be one manufactured by Sony or Matsushita, for 
10 example. The cabin telephone system 239 may be systems manufactured by AT&T or 
GTE, for example. Signals associated with the cabin telephone system 239 are routed 
through the system 100 by means of a CEPT-E1 network 219. 


15 


The passenger entertainment system audio controller (PESC-A) 224a and the passenger 
entertainment system video controller (PESC-V) 224b are similarly designed and have 
similar capabilities. However, some features are implemented only in the PESC-A 224a 
or only in the PESC-V 224b. The passenger entertainment system controller software 
implements specific features particular to the PESC-A 224a or PESC-V 224b. 


20 


25 


30 


The passenger entertainment system controller performs the following functions: 
digitizes up to 32 audio inputs from entertainment and video audio sources, RF 
modulates the digital data, mixes the RF digital audio data with the RF input from a 
VMOD or another passenger entertainment system controller, outputs the combined RF 
video carrier and RF digital audio information to the RF distribution system, inputs up 
to five analog inputs, and multiplex in any combination to a maximum of five analog 
outputs, provides programmable volume control of the five analog outputs, provides RS- 
232, RS-485, ARINC-429, and ARCNET communications interfaces, provides input 
discretes for the control and distribution of PA audio to the seats, provides input and 
output discretes for the control and distribution of video announcement audio to the 
overhead PA system of the aircraft 111, provides input discretes for passenger 
entertainment system controller type and address information, provides input discrete 
for aircraft status fin air /on ground), amplifies output RF, software monitorable and 
controllable, provides an external test /diagnostic communication port, provides 
indicators representing power, operation status, and communication status, provides 


98-PS-039 





- 22 - 


telephone control and distribution (PESC-A 224a onlvh and provides a fault depository 
for BIT data (PESC-A primary 224a only). 

Referring now to Figure 5, it shows a simplified diagram of the system 100 and 
illustrates distribution of video signals from the video cassette player 227 and media 
server 211 to the seat displays 122, To implement video on demand in accordance 
with a preferred embodiment, the media server 211 outputs 30 digital MPEG- 
compressed video transport streams on three video channels (ten streams each), while 
the video cassette player 227 outputs three video streams on three video channels. 

To gain extra throughput, the 30 digital MPEG compressed video streams output by the 
media server 211 are 64-value quadrature amplitude modulated (QAM). However, it is 
to be understood, however, that by using 256-value QAM encoding, for example, the 
number of video programs delivered in each video channel mav be further increased. 
Consequently, the present system 100 is not limited to any specific QAM encoding 
value. 


The video streams from the video cassette player 227 and the quadrature amplitude 
modulated MPEG compressed video transport streams from the media server 211 are 
then modulated by the first video modulator 212a for transmission over the RF cable 
215 to thean audio-video seat-distribution unit 231 at each of the passenger seats 123. 
To provide first class passengers 117, for example, with true video on demand, the 
streams are controlled by the passengers 117, with one stream assigned to each 
passenger that requests video services. 

The simultaneous transfer of video streams derived from both the video cassette player 
227 and the media server 211 in an aircraft entertainment system is considered 
unique. In particular, conventional systems either process analog (NTSC) video signals 
or digital video signals, but do not process both simultaneously. However, in the 
present system 100, NTSC and quadrature amplitude modulated MPEG-compressed 
digital video signals are processed simultaneously through the first video modulator 
212a and distributed to passenger seats 123 for display. 

Obj e ct Ori e nt e d Programming (OOP) i s e mploy e d - in th e softwar e and firmwar e us e d in 
th e syst e m 1 00 , which will now - b e di s cu sse d. A pr e f e rred e mbodim e nt of th e s oftwar e 
u s e d in t - h e-s y s t e m 1 QQ is writt e n using JAVA, C, or th e C+ - + languag e and utiliz es 
obj e ct ori e nt e d programming m e thodology. Obj e ct ori e nt e d programming (QQP) - ha s 
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10 


The first passenger entertainment system controller (PESC-A1 224a is coupled to a 
plurality of area distribution boxes 217 by wav of the RF cable 215 and the ARCNET 
network 216. The area distribution boxes 217 are used to distribute digital and analog 
video streams to the audio-video distribution units 231 at the passenger seats 123. 


Figure 5a is a diagram illustrating the passenger entertainment system controller 
fPESC-A) 224a and a cooperative audio- video unit 231 that provide for distribution of 
quadrature amplitude modulated (QAM) digital audio signals to passenger seats 123 
throughout the aircraft 111. The passenger entertainment system controller 224a 
30 comprises a plurality of analog to digital converters (A/D) 351 that digitize audio input 
signals from input sources, such as one or more audio tape reproducers 223. the public 
address system 222 and a passenger service system 275. The digitized signals from 
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these sources are multiplexed in a multiplexer (MUX) 352 that is controlled by a 
controller 353 and microprocessor (uP) 355 having a programmable memory 354. The 
programmable memory 354 stores code for use by the microprocessor 355 in 
multiplexing the signals. 

The output of the multiplexer 352 is input to a first-in first-out (FIFO) buffer 356 and 
output signals therefrom are quadrature amplitude modulated using a quadrature 
amplitude modulator (QAM) 357. The format of the output signals from the FIFO buffer 
356 is shown and includes a start frame set of bits (header) followed by each of the 
respective audio channels (CHI ... CHn). The output of the quadrature amplitude 
modulator 357 is modulated onto a carrier by an RF modulator 358 that transmits the 
QAM and RF modulated signal over the RF cable 215 to the audio-video units 231 at 
each of the passenger seats 123, 

The audio-video units 231 each comprise a RF tuner 235 that demodulates the RF 
modulated signal transmitted over the RF cable 215 that is coupled to a QAM 
demodulator 237 that demodulates the quadrature amplitude modulated signals. The 
output of the QAM demodulator 237 is converted to an analog signal by a digital to 
analog converter (D/A) 363 and sent to the headphones 132. Selection of a particular 
channel to be listened to by a passenger 117 is made using the tuner 235 that 
demodulates the signal associated with the selected channel. 

The improved quadrature amplitude modulated (QAM) digital audio distribution 
provided by this aspect of the present invention provides for a greater number of audio 
channels to be communicated over the RF cable 215. This is similar to the quadrature 
amplitude modulation of the video streams discussed above with reference to Figure 5. 
The quadrature amplitude modulation provides for a plurality of states (not 
compression) that increases the usage of the bandwidth of the RF cable 215. Any type 
of analog input signal may be processed, including signals from the audio tape 
reproducers 223, passenger address system 222, passenger service system 275 or 
other analog audio source. 

The area distribution equipment 210 distributes information from the head end 
equipment 200 to the seat group equipment 220. The area distribution equipment 210 
also provides power to the seat group equipment 220. Figure 6 is a block diagram 
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n ex t - ar e a di s tribution - box 217. Th e ar e a di s tribution box 217 has an RS 232 s e rial 
diagnostic port to allow v e rification of functionality. 

The area distribution equipment 210 distributes data throughout the communications 
network formed between the head end equipment 200 and the seat group equipment 
220. The area distribution equipment 210 comprises the plurality of area distribution 
boxes 217 that are each coupled to a plurality of floor junction boxes 232 that are 
individually coupled to respective audio-video seat distribution units 231 in the seat 
group equipment 220 of respective columns of passenger seats 123. 

In a basic system, the area distribution box (APB) 217 provides for interfacing the first 
passenger entertainment system controller (PESC-A) 224a to audio-video units 231 
either directly or via floor unction boxes 232. The area distribution boxes 217 interface 
to the audio-video seat distribution units 231 by wav of the junction boxes 232 using 
full-duplex RS-485 interfaces 218 and RF cables 215. The RS-485 interfaces 218 
provide control and data links between the seat group equipment 220 and the head end 
equipment 200. The RF cables 215 couple audio and video data to headphones 132 
and seat displays 122 for listening and viewing by the passengers 117. The area 
distribution box 217 acts as a connection box to facilitate the distribution of system 
power, combined audio /video signals and service data for up to five columns of audio- 
video units 23 1. and relay of service data and combined audio /video signals to the next 
area distribution box 217. The area distribution box 217 has an RS-232 serial 
diagnostic port to allow verification of functionality. 

The area distribution box 217 removes power from a seat column in which either a 
short circuit or ground fault condition is identified. The area distribution box 217 
restores power to a seat column from which power had been removed without requiring 
physical access to the area distribution box 217. When power is reapplied to such a 
column, the short circuit protection circuit functions normally and removes power from 
the column if the short circuit condition persists. An area distribution box 217 
processor monitors the status of the AC power output to each individual AVU column 
for BIT/ BITE purposes. 

The area distribution box 217 provides the means to adiust the RF level in order to 
ensure that the proper RF levels for the video and modulated audio signals are supplied 
to the AVU tuners and demodulators in the presence of changing system configurations 
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and operational conditions. This RF leveling is accomplished by the local processor /s in 
the area distribution box 217 by controlling a variable attenuator. 

The area distribution box 217 provides for interfacing voice data, originating at 
passenger telephones 121c. to the first passenger entertainment system controller 
224a. The telephone interface provides for input data from each AVU column to be 
combined with input data from another area distribution box 217 and retransmitted to 
the first passenger entertainment system controller 224a or the next area distribution 
box 217. 


Figure 7 is a block diagram of exemplary seat group equipment 220 in accordance with 
a preferred embodiment. The seat group equipment 220 allows individual passengers 
117 to interact with the system 100 to view movies, listen to audio, select languages, 
play games, video conference with others on and off the aircraft 111, and interface with 
other interactive services. 


The seat group equipment 220 includes a passenger control unit 121, a seat display 
122, headphones 132, interface 128a for a personal video player 128 (in certain zones), 
an audio-video unit 231 with a plurality of seat controller cards (SCC) 269 one for each 
seat 123 in a row to interface with the area distribution equipment 210, a video camera 
267 and a microphone 268 for use in video conferencing, and a telephone card 271 
that interfaces to the passenger control unit 121 when it includes the telephone 121c 
and/or credit card reader 12 Id. One audio-video unit 231 is provided for each seat 
123 and controls distribution of video, audio and data to the headset or headphones 
132, the seat display 122, and the passenger control unit 121. 

Referring to Figure 3, in certain zones of the aircraft 111, a personal computer interface 
129a is provided which allows the passenger 117 to power a personal computer (not 
shown) and to interface to the system 100 through the audio-video unit 231. 
Alternatively, a keyboard 129b may be provided that allows the passenger 117 to 
interface to the system 100. The use of the personal computer 129a or keyboard 129b 
provides a means for uploading and downloading data by wav of the satellite 
communications system 241 and the Internet. 

The major functional requirements of the audio-video unit 231 are that it drives one to 
three seat display units 122 with or without touch screens, provides touch screen and 
display controls, provides two audio jacks per seat, provides two passenger control unit 
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interfaces per seat 123, interfaces to a parallel telephone system, provides discrete 
signal interface, a parallel laptop power supply system, demodulates and tunes NTSC 
and QAM from the RF signal, provides PC type video games, provides an RS-485 
interface for ADB-AVU or AVU-AVU communications, provides an interface for personal 
video players, and provides a PSS interface to an external parallel passenger service 
system (PSS), provides hardware and software interfaces that provide for video 
teleconferencing and Internet communications. 

Referring to Figure 7, one seat controller card 269 is dedicated to a passenger seat. 
Therefore, three seat controller cards 269 are required for a three-wide audio-video 
unit. Two seat controller cards 269 are required for a two-wide audio-video unit 231. 

A power supply module fPSM) 233 supplies power for the three seat controller cards 
269, an audio card 234, the displays 122, and PCUs 12 3L. The audio card 234 
electrical circuits comprise RF demodulators to supply audio outputs. An interconnect 
card (not shown! connects the three seat controller cards 269, the audio card 234, the 
power supply module 233, and external connectors within the AVU 231. 

The seat controller card (SCC) 269 provides many functions for a single passenger 117. 
Some of the functions that the seat controller card 269 provides include analog video 
and audio demodulation, graphics overlay capability, and Motion Picture Experts Group 
(MPEG) video and audio decompression. The seat controller card 269 provides the 
ability to demodulate the existing analog video signals as well as MPEG encoded signals 
delivered by the media server 211 that comprises a video-on-demand (VQD) server. 

The seat controller cards 269 in Figure 7 and 7a in each audio-video seat distribution 
unit 23 1 contain a tuner 235 that downconverts the modulated RF signals to produce 
intermediate frequency signals containing the NTSC video streams and the quadrature 
amplitude modulated (QAM) MPEG compressed video streams. A QAM demodulator 
237 and an MPEG decoder 238 are used to demodulate and decompress the 
Quadrature amplitude modulated and compressed MPEG compressed video streams to 
produce MPEG NTSC video and audio signals for display. 

An analog (video) demodulator 236 demodulates the NTSC video signals that are then 
passed to a video multiplexer 235a where an external NTSC video signal may be added. 
The NTSC signals are then digitized in a video A/D converter 235b and are passed to 
the MPEG decoder 238. The format of the digital channels after QAM demodulation is 
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MPEG-2 transport streams. The MPEG-2 transport streams may contain many streams 
of video, audio and data information. The MPEG decoder 238 (demultiplexer) may also 
receive data information to be sent to the SCC processor group 272. In the MPEG 
transport group, the capability exists to add text overlay with the digital video data. 

The digital data is converted to analog NTSC format using an NTSC encoder 238a for 
the display 122, 


10 
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Each of the seat controller cards 269 includes a microprocessor (mP) 272 that controls 
the tuner. The microprocessor 272 is used to address the seat controller card 269 as a 
node on the network. A database is set up in the cabin file server 268 that includes 
entries for each of the microprocessors (i.e., each seat 123K The addressability feature 
permits programming of each seat to receive certain types of data. Thus, each audio- 
video unit 23 1 may be programmed to selectively receive certain videos or groups of 
video selections, or audio selections from selected audio reproducers. The 
addressability aspect of the present system 100 allows the airline to put together 
entertainment "packages" for distribution to different zones or groups of seats. Also, 
each seat (or seats in different zones) may be programmed to be able to play games, use 
the telephones 121c and credit card reader 12 Id, use a personal video player or 
computer, have the ability to engage in video teleconferencing and computer data 
interchange, or gain access to the Internet, Furthermore, the addressability associated 
with each seat permits order processing and tracking, and control over menus that are 
available to passengers at respective seats, for example. The addressability feature also 
permits dynamic reconfiguration of the total entertainment system 100. 


To provide control from passenger seats 123, the microprocessor 272 in the audio- 
video unit 231 includes software that performs substantially the same functions as 
25 those in the primary access terminal 225, This may be achieved by selectively 

downloading a software module to the microprocessor 269 in the audio-video unit 231 
when the passenger 117 requests this service. The downloaded software module 
operates in the same manner as the software on the primary access terminal 225, 
However, the RS-485 interface is used to send commands to the cabin file server 268 
30 that control the ARINC-485 driver. Alternatively, and preferably, use of an Ethernet 

network 228 to interconnect the audio-video units 231 provides a readily implemented 
control path directly to the primary access terminal 225 and cabin file server 268, 
since they are normally connected by wav of the Ethernet network 228. 
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The audio card 234 in Figure 7 provides several functions. It demodulates the RF 
signal to provide audio. It has a multiplexer with audio inputs from the seat controller 
card 269, demodulated RF signal audio, and external audio. It routes the 115 VAC 
power to the power supply module and routes the DC power from the power supply 
module 233 to the interconnect card. 


Figure 7b illustrates a typical fixed passenger control unit 121. The passenger control 
unit (PCUj 121 interfaces with the system 100 via the audio-video unit fAVUl 231 and 
provides a passenger interface having input controls 381 and indicators 382. The 
passenger control unit 121 communicates with the audio-video unit 231 for PCU/AVU 
data, AVU/PCU data, and power. 

The passenger control unit 12 1 may be either side mounted or top mounted onto a seat 
123 arm rest. The passenger control unit 121 has a four character alphanumeric 
display 389. Brightness of the LED display 389 is controllable, as a minimum, to two 
levels of brightness. The passenger control unit display 389 is controlled bv the audio- 
video unit 231 to inform the passenger of current mode status and video functions. 

The passenger control unit 121 also comprises depressible buttons that permit 
selection of items displayed on the seat display 122 and turn on call lights and 
overhead lights, and electronics. In designated sections or seats, the passengers also 
control selection of movies and games that are to be played, control the landscape 
cameras, and activate video conferencing and data communications. In selected 
sections (business and first class) of the aircraft 111, the telephone 121c and credit 
card reader 12 Id are integrated into the passenger control unit 121. while in other 
sections (such as coach class! these components are not provided. 

A reading light on /off function key 382a turns on /off an overhead reading light. Call 
light on and call cancel function keys 382b. 382c permit calling a flight attendant. A 
volume control (increase /decrease volumel key 383 is provided. A select function key 
384 allows the passenger to make a selection. Screen navigation function keys 385 
provide a means for a passenger 1 17 to navigate through menus displayed on the 
display 122 or seat display unit fSDU) 122a. A channel up/down function kev 386 
provides for channel control (increase /decrease channel selection). A TV/OFF function 
key 387 turns the seat display unit backlight on. Pressing a mode function kev 388 
allows the passenger to have picture adjustment control of the seat video display 
through menus displayed on the seat display unit 122a. 
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The passenger control unit 121 interfaces to the credit card reader 12 Id. The credit 
card reader 12 Id reads three magnetically encoded tracks from credit cards that are 
encoded in accordance with ISO standards 7810 and 781 L Data content is read in 
accordance with the VisaNet Standards Manual and contain at least: major industry 
identifier, issuer identifier, primary account number, surname, first name, middle 
initial, expiration date, service code, and PIN verification data. 

Figure 8 is a block diagram of exemplary overhead equipment 230 in accordance with a 
preferred embodiment. The overhead equipment 230 comprises a plurality of tapping 
units 261 coupled to the overhead and bulkhead displays 263 and video projectors 
262. The overhead equipment 230 uses RF video distribution, wherein the RF signal is 
distributed from the head end equipment 200 to the overhead equipment 230 via the 
plurality of tapping units 261 which are connected in series. The tapping units 261 
contain tuners 235 to select and demodulate the RF signal providing video for the 
monitors 263 and projectors 262 coupled thereto. Control is provided to the overhead 
equipment 230 using an RS-485 interface 264 coupled to the first passenger 
entertainment system controller (PESC-A) 224a. The information on the RS-485 
interface 218 between the first passenger entertainment system controller (PESC-A) 
224a and the tapping units 261 is controlled via operator input and protocol software 
running on the cabin file server 268. 

In order to efficiently implement video teleconferencing, the use of a higher speed, 
larger bandwidth communication network may be provided to permit many 
simultaneous uses. This is achieved using a high speed network, such as the 100 
Base-T Ethernet network 228 that is currently employed in the head end equipment 
200. Interconnection of each of the audio-video seat distribution units 231 by wav of a 
100 Base-T Ethernet network 228 in addition to, or which replaces the lower 
bandwidth RS-485 network 218, provides substantial bandwidth to implement video 
teleconferencing. 

Interconnection of the audio- video seat distribution units 231 using the 100 Base-T 
Ethernet network 228 also permits data communications between personal computers 
located at the seats 123 and remote computers 112. This is achieved bv interfacing the 
100 Base-T Ethernet network 228 to the satellite communications system 241. Inter- 
computer telecommunications may be readily achieved using a Web browser running on 
portable computers connected to the audio- video seat distribution units 231, or bv 
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integrating a Web browser into the audio-video seat distribution units 231. This is 
readily achieved by running the Web browser on the microprocessor 272 used in each 
audio-video seat distribution unit 231. Messages may be drafted using a keyboard 
129b connected to the audio-video seat distribution units 231. Touchscreen seat 
displays 122 may be also readily programmed to initiate actions necessary to initiate 
videoconferencing, initiate communications, transfer messages, and other required 
actions. 


10 


Certain line replaceable unit types require the assignment of a unique address within 
the system 100. This is referred to as line replaceable unit addressing. Line 
replaceable units that require unique addresses are the PESC-A primary /secondary 
224a, PESC-V 224b, video reproducers 227. area distribution box 217, tapping unit 
261, and primary access terminal 225. Each of these line replaceable unit types is 
assigned a unique address during system installation. 


Referring again to Figure 2, it depicts the architecture of the system 100, and its 
15 operation will now be described with reference to this figure. The architecture of the 
system 100 is centered on RF signal distribution of video, audio, and data from the 
head end equipment 200 to the seat group equipment 220. Video and audio 
information is modulated onto an RF carrier in the head end equipment 200 via the 
video modulator 212a and passenger entertainment system controllers 224a, 224b 
20 respectively prior to distribution throughout the aircraft 111, Referring again to Figure 
5, it shows a functional block diagram of the signal flow to and from the head end 
equipment 200. 


25 


The source of video may be from video cassette players 227, landscape cameras 213, 
and the TV video output by the media server 211, or the passenger video information 
system 214. The source of audio information may be from audio reproducers 223, 
audio from video cassette players 227, or audio from the passenger address system 
222 . 


30 


The system 100 uses the RF network 215 to distribute all audio and video 
programming from the head end equipment 200 to the seats 123. The RF network 215 
is also used to support downloading of video games and other applications to the seats 
123. 
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The RF network 215 operates over a nominal frequency range from 44 to 550 MHz. The 
system 100 provides up to 48 6-MHz wide channels for distribution of video 
information. One of these channels may be used for the distribution of video games 
and other application software to the seats 123, The video channels are allocated to a 
bandwidth from 61.25 through 242.6 MHz (nominal). The frequency range from 108 to 
137 MHz (nominal) remains unused. 


The frequency range from 300 to 550 MHz is used for distribution of audio information 
to the seats 123. One embodiment of the system 100 uses pulse code modulation to 
transmit the audio data over the allocated frequency range. This supports a maximum 
10 of 88 mono audio channels (83 entertainment and five PA). The allocation of these 
channels to audio reproducers 223 (entertainment audio), video reproducers 227 
(movie audio tracks) and to passenger address lines (PA audio) is database configurable 
and may be defined by the user. It is also possible to read and set RF levels for the 
passenger entertainment system controllers 224a, 224b and area distribution box 217 
15 by means of an off-line maintenance program. 


20 


The system 100 uses the ARCNET network 216 as the major data communications 
path between major components. The ARCNET network 216 interconnects the 
following components: cabin file server 268, primary access terminal 225, PESC-A 
(primary) 224a, PESC-A (secondary) 224a, PESC-V 224b, and all the area distribution 
boxes 217. 


The ARCNET network 216 is implemented as two physical networks, with the primary 
PESC-A 224a serving as a bridge /router between the two. Any device on ARCNET 1 
216 is addressable by any device on ARCNET 2 216 and vice versa. In addition to the 
primary PESC-A 224a, ARCNET 1 216 connects the following components: cabin file 

25 server 268. and a maximum of eight area distribution boxes 217. In addition to the 
primary PESC-A 224a, ARCNET 2 224b connects the following components: a 
maximum of one PESC-V 224b, primary access terminal 225, and the secondary PESC- 
A 224a. Both ARCNET subnetworks (ARCNET L ARCNET 2) 216 operate at a data 
transmission speed of 1.25 Mbps. 

30 System Operation 

A preferred embodiment of the in-flight entertainment system 100 operates in three 
possible states. These states include 1) a configuration state, 2) a ground maintenance 
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state, and 3) an entertainment state. In the configuration state, aircraft-installation- 
unique parameters are initialized and modified. The configuration state is initiated by 
an operator. The configuration state is entered and exited without the use of additional 
or modified system hardware. In the ground maintenance state, the system 100 
5 performs self-diagnostics to determine system failures. The ground maintenance state 
is initiated by an operator. The ground maintenance state is entered and exited without 
the use of additional or modified system hardware. The entertainment state is the 
primary state of the system 100 and is initiated by the operator. The system 100 
provides several entertainment modes as defined below. The system 100 is modular in 
10 design so any one or all modes may exist simultaneously depending on the configura- 
tion of the system 100. The system 100 is configurable so that each zone (first class, 
business class, coach class, for example) of the aircraft 111 can operate in a different 
entertainment mode. In the entertainment state, the passenger address functions and 
passenger service functions are independent of the mode of operation. 


15 


20 


25 


The entertainment modes include an overhead video mode, a distributed video mode, 
and an interactive video mode. In the overhead video mode, video is displayed in the 
aircraft 111 on the overhead monitors 263. Different video entertainment is possible 
for different sections of the aircraft. In the distributed video mode, multiple video 
programs are distributed to the individual passengers of the aircraft at their seat. The 
passenger selects the video program to view. The quantity of programs available 
depends upon system configuration. In the interactive video mode, the system 100 
provides a selection of features in a graphical user interface (GUI) presentation to the 
passenger. Depending on the system configuration, the features may include language 
selection, audio selection, movie selection, video game selection, surveys, and display 
settings. 


30 


Th e ar e a distribution box 217 utiliz es and di s tribut es s ingl e pha se^- l 15 VAC, 4 00 Hz 
pow e r to e ach AVU column output. — Th e ar e a di s tribution box 31 - 7 provid es 
distribution of a maximum of 7.5 Amp s (continuou s ) to e ach individual - column. Th e 
total AC pow e r consumption of th e ar e a di s tribution box 33 1 # i 6 4 6 Watts nominal, 0. 4 0 
Amp e r es nominal. Th e ar e a distribution box 317 moniters - th e AC pow e r output to e ach 
i ndividual AVU column and id e ntifi es curr e nt draw in e xc ess of 7.5 AMPS - for a duration 
in e xc e ss of 200 millis e cond s a s a short circuit condition. Th e ar e a di s tribution box 
S I 7 monitors th e AC pow e r output to e ach - individual AVU column and id e ntifi e s 
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u nbalanc e d curr e nt b e tw ee n th e AC HI and - LO lin es in e xc es s of 50 - ma - for a duration 
in e xc es s of 200 millis e cond s a s a ground fault condition. 

Th e ar e a distribution box 217 r e mov e s pow e r from a se at column in which e ith e r a 
s hort circuit or ground fault condition is id e ntifi e d, - Th e ar e a distribution box 33 L? 
r es tor es pow e r to a s e at column from which pow e r had b ee n r e mov e d without r e quiring 
phy s ical acc e s s to th e ar e a di s tribution box 217. Wh e n pow e r i s r e appli e d to s uch a 
column, th e s hort circuit prot e ction circuit functions normally and r e mov es- pow e r from 
th e column if th e short circuit condition p e rsists. Th e ar e a di s tribution box 2 
p roc es sor/ s monitor s th e- s tatu s of th e AC pow e r output to e ach individual AVU column 
for BIT/ BITE purpos e s. 

The system 100 provides audio programming to the passengers. When in the 
interactive audio mode of operation, the system 100 displays a list of audio programs 
available to the passenger on the seat display 122. This list is configurable via an off- 
line database. The system 100 may be configured to allow selection of an audio 
program using either the seat display 122 or controls on the passenger control unit 
121 depending on the system 100 requirements. The selected audio program is routed 
to the corresponding passenger headphone 132. 

The system 100 provides video programming to all passengers 117. When in the 
interactive video mode of operation, the system 100 displays a list of video programs 
available to the passenger on the screen of the seat display unit 122a. This list is 
specified via an off-line database. The system 100 may be configured to allow selection 
of a video program using either the seat display 122 or controls on the passenger 
control unit 121 depending on the system requirements. The selected video program is 
routed to the corresponding seat display unit 122. 

When in the interactive mode of operation, the system 100 provides video games to the 
passengers 117. The system 100 displays a list of up to 10 video games available to 
the passenger on the seat display 122. This list is specified via an off-line database. 

The system 100 may be configured to allow selection of a video game using either the 
seat display unit 122a or controls on the passenger control unit 121 depending on the 
system requirements. The selected video game is downloaded to the corresponding 
passenger seat 123 for viewing on the seat display 122, 

The system 100 supports entertainment packaging. An entertainment package is a 
predetermined set of one or more movie titles and/or game titles with a predetermined 
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amount of game play time. The content of each entertainment package is specified via 
an off-line database. The system 100 requires payment for entertainment packages 
according to a unit price and a price policy. The system 100 displays a list of available 
packages on the screen the seat display unit 122a. Each package in this list must have 
an associated date range that specifies when the package is available. Up to four 
packages per date range are specified via an off-line database. The displayed list only 
contains those packages where the date of the current flight falls within the date range 
specified for that particular package. 

As is shown in Figure 7, for example, if configured with a personal video player 128 
that interfaces to the audio-video unit 231 by wav of a personal video player interface 
128 a, the system 100 controls the personal video player 128 via controls at the seat 
display 122, The system 100 provides commands to the personal video player 128 to 
play, rewind, fast forward, pause, stop and eject a tape. 

The system 100 provides the ability to place telephone calls from each passenger seat 
123. In certain configurations, the telephone handset is integrated into the passenger 
control unit 121. The handset includes a telephone button pad, a microphone, and a 
speaker. The system 100 prompts for payment when using the telephone service. 
Payment must be made via a credit card. The system 100 provides the capability to 
enter the phone number via controls on the passenger control unit 121. The system 
100 also displays phone call status on the screen of the seat display 122. 

The system 100 provides the ability for passengers 117 to select items from an 
electronic catalog displayed on the screen of the seat display 122. The catalog may be 
divided into categories. The system 100 provides the capability to configure the 
categories and the items via an off-line database tool. 


The system 100 provides the capability to display on the screen of the seat display 122 
a running tabulation of all expenses, excluding telephone charges, incurred at a seat 
during the current flight. 

\ 

The system 100 is configured to allow the flight attendants to display flight information 
at the primary access terminal 225 from the off-line database or retrieved from other 
equipment on-board the aircraft 111. If this information is not available, the system 
100 is configured to allow information to be entered manually at the operator console 
as detailed below. Flight information may include the following: aircraft registration 
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number, flight number, departure airport, arrival airport, flight duration, and route 
type. 

System Software 

The system 100 employs a software architecture that integrates processing performed 
by each of the subsystems. The software and firmware comprising the software 
architecture controls the system, manages the flow of analog and digital audio and 
video data to passenger consoles and displays, manages the flow of communications 
data, and manages service and order processing. Various subsystems also have their 
own software architectures that are integrated into the overall system software 
architecture. 


The system software is designed in a layered fashion, and an application programming 
interface (API) layer is defined and documented for the primary access terminal 225 
and seat display 122. These application programming interfaces are used as the 
foundation upon which to implement the graphical user interfaces (GUIs). The GUIs 
are thus implemented in a manner that facilitates rapid prototyping and GUI 
modification within the constraints of the services provided by the application 
programming interfaces. The system 100 has a flight attendant GUI at the primary 
access terminal 225 and passenger GUIs at the seat 123 (seat display unit 122ah 
Each of these GUIs have the following properties: graphic orientation, clear and directly 
selectable functions (no "hidden" functions), consistency in screen layout and flow (look 
and feel), and "lexical" feedback (i.e., visible change on the display) for every user 
action. 


Many of the line replaceable units in the system 100 are software loadable in that the 
contents of the line replaceable unit's memory can be overwritten from a source 
external to the line replaceable unit. The system 100 provides a facility for loading 
software into all line replaceable units. The software loading facility ensures that any 
attempt to load software into a line replaceable unit is appropriate for that type of line 
replaceable unit. The software loading function indicates when a line replaceable unit 
can and can not be loaded, the status of software load attempts as either successful or 
unsuccessful, and an estimate of the time required to load the software into the line 
replaceable unit. The software load facility employs a high speed download link to the 
line replaceable units, when appropriate, in order to minimize the time required to load 
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software into a line replaceable unit. The software loading facility precludes load 
attempts when the aircraft 1 1 1 is in flight. 


5 


10 


15 


Software and firmware employed in the present invention permits credit card 
processing, data collection processing, Internet processing for each passenger, gambling 
for each passenger, duty free ordering, intra-cabin audio communication between 
passengers, and display of flight information. The system software includes parallel 
telephone system software, landscape camera management software, PESC system 
software, passenger address override software, passenger address emergency software, 
monetary transaction processing software, language support software, built-in-test 
software, user request processing software, database management software using a 
distributed configuration database, software for implementing interactive access, 
software for processing passenger orders, software for updating inventories, application 
software, media file encryption software, area distribution box software, audio-video 
unit programming software, telephone operation software, gatelink node and software, 
product service pricing software, passenger survey software, transaction reporting 
software, automatic seat availability reporting software, and video conferencing and 
data communications software. 


20 


25 


Object oriented programming (OOP) is employed in the software and firmware used in 
the system 100. A preferred embodiment of the software used in the system 100 is 
written using JAVA, C, or the C++ language and utilizes object oriented programming 
methodology. Object oriented programming (OOP) has become increasingly used to 
develop complex applications. As OOP moves toward the mainstream of software design 
and development, various software solutions require adaptation to make use of the 
benefits of OOP. A need exists for these principles of OOP to be applied to a passenger 
entertainment system such that a set of OOP classes and objects for the messaging 
interface can be provided. 


30 


The system 100 is constructed in a modular framework, and is designed to expand to 
support various aircraft 111 configurations. System configuration information is 
defined in an off-line configurable database. System configuration support tools 
provide the capability to generate database information, which is downloaded to the 
appropriate system line replaceable units. The line replaceable units store database 
information in non-volatile memory, and revert to default database information when 
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thev detect newly downloaded data inconsistent with the physical aircraft configuration. 
or when a database download is unsuccessful. 


Aircraft configuration data requires modification only when the aircraft configuration 
changes, or when the line replaceable unit in which it resides has been replaced or 
corrupted. Aircraft configuration data at a minimum includes the following fields: 
Aircraft type, ACS database configuration ID. Overhead system type. Seat configuration, 
tapping unit and Overhead monitor assignments. Reading /Call light assignment. 

Master call lamps /attendant chimes data. RF level gain values. Internal ARCNET 
termination. PA/VA headphone. APAX-140-to-TES interface assignments. PESC audio 
channel assignments’ VMQD video channel assignments. APB phone capability. APB 
discretes. PA zone, display controller, configuration of passenger entertainment system 
controllers 224. interactive /distributed video only (DVO), PAT/CFS options, and movie 
preview. 

The entertainment system data define specific parameters for the available system 
features. It is necessary to reload the database whenever it is determined the 
associated features are to be changed. Entertainment system data, at a minimum, 
includes the following fields: Entertainment system data configuration ID. Video games. 
Movies. Pay /Free entertainment per zone. Passenger surveys per zone. General 
service /Duty free zones, seat display unit entertainment titles per route type. Currency 
exchange rates, primary access terminal display currency. Airline name, flight number, 
arrival /departure city, flight duration, and route type. Movie cycle attributes. Video 
announcements, video reproducer entertainment assignments. Product data. Credit 
card data, and Entertainment package details. 

Figure 9 is a block diagram of the ACS tool and shows its functionality. The ACS tool 
provides hardware, user, software, and database interfaces as described below. The 
ACS tool supports the following hardware interfaces. The ACS tool supports a standard 
101 key PC keyboard for the PC application and the primary access terminal standard 
keyboard. The ACS tool supports a standard MICROSOFT mouse, or equivalent, for the 
PC application. The off-line configuration database tools support generation of all 
downloadable configuration data. Airplane Configuration System (ACS) tools are used 
to generate aircraft configuration system data. The ACS tool is executable on an IBM- 
compatible 486 PC running MICROSOFT WINDOWS 3.1 or a later version. The ACS 
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tool produces downloadable data file on media that may be directly input via the 
primary access terminal 225 or a maintenance PC connected to a test port. 

The ACS tool provides the following user interfaces. In general, the graphical user 
interface includes a series of screens with buttons and other controls and indicators. 
5 Screens, buttons, other controls, and indicators follow the general conventions for 
WINDOWS screens as described in The Windows Interface Guidelines for Software 
Design . The GUI provides user access to the ACS tool's functions via keyboard and 
mouse inputs. 

The ACS tool provides the functionality to maintain multiple configurations for all the 
10 aircraft types the TES 100 and APAX-150 systems support. The ACS tool is a single 
executable, regardless of aircraft type. This single executable utilizes a configuration 
file for pre-initialization of aircraft configuration data (.CFG). It also utilizes a 
WINDOWS.INI file for ACS tool-specific parameter definition. 


15 


The ACS tool generates configuration data files that can be distributed to the TES line 
replaceable units. The applicable data files may be downloaded upon operator request 
via the MAI NT Utility. 


20 


The ACS tool provides the ability to create and change an aircraft configuration by the 
use of menus, list boxes, data entry screens, utilities, error messages and help 
functions. An aircraft configuration defines what TES devices are installed on the 
aircraft, where those devices are located and what functions those devices perform. 


The PESC-A 224a, PESC-V 224b, area distribution box 217, APB local area controller 
fALAC) (not shown), AVU/SEB 231, and overhead electronic box (not shown! line 
replaceable units, as well as the primary access terminal 225 and cabin file server 268, 
the MAINT and Config/ Status utilities all require knowledge of the aircraft 
25 configuration. The database created by the ACS tool that can be downloaded into the 
PESC-A 224a and contains the configuration data needed by the PESC-A 224a, PESC- 
V 224b, area distribution boxes 217, ALACs, AVUs/SEBs 231. tapping units 261, and 
overhead electronics boxes. The ACS tool has the capability to create separate 
configuration data files for the primary access terminal 225 and cabin file server 268 
30 and the MAINT and Config/ Status Utilities. 
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The ACS tool also has the capability to create downloadable data files that can be 
loaded directly into the area distribution boxes 217 . The data files that the ACS tool 
creates for the primary access terminal 225 and cabin file server 268 are able to be 
imported by the primary access terminal 225 and cabin file server 268 into its 
5 database. These files provide information about the aircraft 111 so that interactive 
services can be provided to the passengers. 

The ACS tool creates a downloadable data file f.INT File! that is able to be used by the 
MAI NT and Config/Status Utilities to determine system-wide LRU status, software 
configuration, and diagnostic information. These utilities require system configuration 
10 definition data. 


The ACS tool provides a configuration editor function that allows the user to modify an 
existing aircraft configuration or generate a new aircraft configuration by entering 
values into displayed data fields or bv selecting values from drop-down menus, if 
applicable. The configuration editor allows the user to import, or copy, selected aircraft 
15 configuration data from one configuration to another, "cut" and "paste' 1 operations are 
provided so that similar or identical configuration entries may be copied from one 
configuration to another. The configuration editor validates the value entered for each 
data field. The ACS tool generates error messages when the user enters invalid data in 
dialog boxes. The configuration editor provides the capability to save a configuration to 
20 disk. The ACS tool provides the capability to initiate a configuration validation test. If 
the validation test finds errors with the data, a detailed error report is displayed. The 
ACS tool allows a configuration that is INVALID to be saved to disk (.CFG). but the ACS 
tool does not allow a downloadable database to be built from a configuration that is 
INVALID. 


25 


A configuration data builder function of the ACS tool System provides the capability to 
generate downloadable configuration data files for use with the system 100 and 
peripherals. When the user attempts to create the downloadable data files, the ACS 
tool performs a validation check and tests for limits. 


30 


A reports generator function of the ACS tool provides the capability to generate, for a 
specified configuration, a validation report and a configuration report.. A validation 
report contains information defining the validity of a specified configuration, including 
appropriate messages for entries in the configuration which are currently invalid. A 
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validation report may be generated upon user request or upon request to generate 
download files. The configuration report provides a detailed report which describes the 
current configuration. The configuration report is generated only when a request to 
generate download files is made and the current configuration is determined to be valid. 

A create floppy disk function of the ACS tool provides the capability to generate a disk 
that contains all files generated by the ACS tool. These downloadable configuration 
files are loaded to the various line replaceable units in the system. The diskette also 
contains a setup utility that can be run from the primary access terminal 225 to 
reinitialize the database on the cabin file server 268 with a new configuration. 

Each line replaceable unit that uses the database contains electrically erasable 
programmable read-only memory (EEPROM) which are ''downloaded' 1 with the database. 
This means that the database which contains information about the airplane 
configuration can be passed to each controller (i.e., downloaded). These controllers 
include the PESC-A 224a, PESC-V 224b, area distribution boxes 217, ALACs, SEBs 
(AVUs) and overhead electronic boxes. 

Many different configurations can be stored for an aircraft 111. Each contains slightly 
different options, such as the seating configuration. The ACS tool enables the different 
configurations, after established, to be recalled season after season by allowing the user 
to select an existing configuration to edit when a change is made to the aircraft 111 
during re-configuration. The ACS tool allows the user to create a new configuration 
that can subsequently be saved. 

Presented below is software design information for a set of programs common to the 
cabin file server 268 and primary access terminal 225 LRUs of the system 100. The 
software forms the fundamental mechanism of moving application information through 
the system 100. The following description will be readily understood to those familiar 
with C++ and the WINDOWS NT development environment. Reference is made to 
Figure 10, which illustrates a block diagram of the software architecture in accordance 
with a preferred embodiment. The architecture facilitates a control center runtime that 
is implemented in C++ for the primary access terminal 225 and the cabin file server 
268 of an in-flight entertainment system 100. 

As for the primary access terminal 225. an uninterruptable power supply 400 is used 
to provide power to the primary access terminal 225 and is in communication with the 


98-PS-039 



-55- 


5 


programs in the software architecture using a serial NT driver 401. A PI board 402 
provides a communication port for the magnetic card reader and video tuner and 
interfaces to the serial NT driver 401. The tuner 235 in the audio-video unit 231 also 
interfaces to the serial NT driver 401. The video camera 267 coupled to the audio-video 
unit 231 is also coupled to the serial NT driver 401. The serial NT driver 401 also 
interfaces with the PESC-V 224b. An ARCNET driver 408 interfaces to the ARCNET 
network 216. 


10 


15 


20 


The serial NT driver 401 and ARCNET driver 408 interface to an I/O handler 403 to 
provide selective communications between a message processor 404 and the various 
communications devices (400. 402, 235, and 267). The message processor 404 is 
responsible for processing messages and putting them into a common format for use by 
a transaction dispatcher 421. A pipe processor 405 is utilized to move common format 
messages from the message processor 404 through a primary access terminal network 
addressing unit (NAU) program 409 and through another pipe processor 420 into the 
transaction dispatcher 421. The message processor 404 also interfaces to a system 
monitor 412 that is coupled to a watch dog driver 410 that is used to automatically 
reset the primary access terminal 225 if no activity is detected in a given time interval, 
and a power down module 414 that performs graceful power down of the primary 
access terminal 225. The transaction dispatcher 421 interfaces with a cabin 
application programming interface (CAPI) library DLL 427 by means of a CAPI message 
service handler 422. 


A touch panel NT driver 424 interfaces with runtime utilities 425 and a graphical user 
interface (GUI) 426 to provide operator control over the software. The runtime utilities 
425 and graphical user interface 426 interface to the CAPI library DLL 427. a Reports 
25 DLL 429 and a video driver DLL and system (SYS) 430. 

The Ethernet network 228 is used for messaging between the primary access terminal 
225 and the cabin file server 268. The Ethernet network 228 interfaces to the primary 
access terminal network addressing unit 409, the transaction dispatcher 421, the CAPI 
Library DLL 427, and the Reports DLL 429. 

30 As for the cabin file server 268, an uninterruptible power supply 440 is used to provide 
power to the cabin file server 268 and is in communication with the programs in the 
software architecture using a serial NT driver 447. The serial NT driver 447 is also 
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I coupled to an auxiliary port 441 and the video reproducers 227. An ARINC-429 NT 



212a. 


The serial NT driver 447. ARCNET driver 450 and ARINC-429 NT driver 448 interface to 
an I/O handler 451 to provide selective communications between a message processor 
452 and the various communications devices 1440. 441. 227. 216. 212a). The 
message processor 452 is responsible for processing messages and putting them into a 
common format for use by a transaction dispatcher 473. A pipe processor 456 is 
utilized to move common format messages from the message processor 452 through 
various network addressing units 461-465 and through another pipe processor 470 
into the transaction dispatcher 473. The network addressing units 461-465 include a 
test port NAU program 461. a VCP NAU program 462. a backbone NAU program 463. 
an ARINC-485 NAU program 464 and a seat NAU program 465. 

The message processor 452 also interfaces to a system monitor 454 that is coupled to a 
watch dog driver 446 that is used to automatically reset the cabin file server 268 if no 
activity is detected in a given time interval, and a power down module 455 that 
performs graceful power down of the cabin file server 268. Each of the network 
addressing units 461-465 is coupled to the system monitor 454. The system monitor 
454 is also coupled to the transaction dispatcher 473. The transaction dispatcher 473 
interfaces with CAPI services 477 that are called from the CAPI message service handler 
422 in the primary access terminal 225. The transaction dispatcher 473 also 
interfaces to the primary access terminal 225 by wav of the Ethernet network 228. 


Cabin Application Programming Interface fCAPIl calls 476 are used to communicate 
information fas shown by arrow 4751 between various cabin services 477 and the 
primary access terminal 225 via the Ethernet network 228 and various service 
interfaces. The separate communication link for the crystal reports DLL 429 is enabled 
through object oriented data base calls 434 to the Standard Query Language (SOLI 
server 492. The cabin services 477 include CAPI calls 476 with predefined formats for 
various services. The services include in-flight entertainment (IFE1 control 478. movie 
cycle 479,video services 480. video announcement 481, game rental 482. movie sales 
483. catalog sales 484. drink sales 485. duty-free sales 486. landscape camera 487, 
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I media server 488, Internet 489 and teleconferencing 490. Each of these services are 



473, through the associated NAU program 461-465, the message processor 452, and 
the relevant driver 447, 448, 449, 450, to the appropriate device 440, 441, 227, 240, 
241. 216, 212b. 


More specifically, the cabin file server 268 and primary access terminal 225 software 
comprises a control center common executive that includes the message processors 
404 and 452, transaction dispatchers 421 and 473, and network addressable unit 
(NAU) programs 409, 461-465 that together manage communications flow among line 
replaceable units and applications, and record or log system irregularities for 
subsequent analysis. The control center common executive efficiently moves 
information from source to destination with a minimum of system resources, provides 
real-time expense or over-handling, provides a means to allow communications to 
originate at any source, including periodic status messages such as those to the 
primary access terminal 225 from the video players 227, and provides a consistent 
method of handling existing line replaceable units while allowing for additional line 
replaceable units. In addition, the common executive stores drivers that are not 
already part of the operating system. The system monitors 412 and 454 are provided 
to launch all application programs and shut them down as needed. 


Each line replaceable unit type that communicates with the control center common 
executive has a corresponding network addressable unit (NAU) program 461-465. For 
example, any seat 123 that must communicate routes to the seat NAU program 465, 
any video cassette player 227 routes to the VCP NAU program 461, etc. Each time a 
line replaceable unit communicates with an NAU program 461-465, a virtual LRU is 
used to maintain cohesion between the application (service) and the device (driver). The 
virtual LRU is a state machine, one for each physical device associated to this NAU 
type. For example, if two seats "001 A" and "02 1J" are communicating with the control 
center common executive, two virtual seat LRUs exist within the seat NAU program 
465. It is within this state machine that the actual conversion between IFE-message 
and native messages takes place. Status and other information regarding each line 
replaceable unit are maintained in the VLRU. 
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In addition to the device-initiated VLRUs. several VLRUs are provided whose function is 
to maintain the status of related devices. For example, the primary access terminal 
225 must constantly monitor the status of the printer, so a VLRU for the printer is 
used in primary access terminal NAU program 409. Similarly, the seats must be kept 
apprised of changes to the states of the system, so a VLRU for broadcasting this 
information is created in the seat NAU program 465. 

Primary Access Terminal 

The primary access terminal executive extension set of routines that, together with the 
common executive software, form the generic application for the primary access 
terminal 225. 


The message processor 404 is shown in Figure 1 1 . which illustrates the message 
processor function and data paths. The message processor 404 interfaces a plurality of 
device drivers 531. including an ARCNET driver 531a and a serial NT driver 531b. The 
device drivers 531 are coupled to a plurality of device handlers 532. The device 
handlers 532 include MessageFromDriversO 532a and MessageToDriversO 532b. The 
MessageToDriversO 532b associated with the serial NT driver 53 lb is coupled to a 
ToDriverOueue 532c. and the MessageToDriversO 532b associated with the serial NT 
driver 531a is coupled to an ArcnetHandler FIFO 532<L 

A NAU server 535 is provided that includes two named pipes (or communication lines! 

having a plurality of InPipeProcessorsO 535a and OutPipeProcessorsO 535b. The 

InPipeProcessorsO 535a and OutPipeProcessorsO 535b are coupled by wav of a plurality 

1 

of pipes 537a to NAU clients 533. The respective InPipeProcessorsO 535a are coupled 
to a corresponding plurality of NAU out FIFO queues 538. 

A plurality of routers 537 coupled the device handlers 532 to the NAU server 535. The 
plurality of routers 537 include the AddMessageToPipeProcessorO 536. an 
AddMessageToOutOueueO 539a. and a MessageToHanderO 539b. The 
MessageFromPriversO 532a of the device handlers 532 are coupled to the 
MessageToPipeProcessorO 536. The InPipeProcessorsO 535a are coupled to the 
MessageToHanderO 539b. The AddMessageToPipeProcessorO 536 and the 
MessageToHanderO 539b are coupled to the LRU table 534. 
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The primary duty of the message processor 404 is to move communications between 
various I/O devices and their appropriate logical devices, the network addressable unit 
(NAU) 533. This duty is assigned to the message processor 404 instead of residing with 
the NAUs 533 because there is no one-to-one correspondence between the NAUs 533 
and the device drivers 531. For example, several devices' communications may arrive 
via an ARCNET driver 531a (i.e., passenger entertainment system controller 224, seat 
123, area distribution box 217, and AVU/SEB 231). 


10 


15 


20 


To- support this duty, the message processor 404 includes the following sub-functions. 
Using an I/O handler 532, the message processor 404 receives messages from the 
device drivers 531, Each message, regardless of original format must contain a 
destination or network address for routing purposes. Using this network address 
coupled with the device type (i.e., ARCNET, RS-232, etc.) the network address 
determines the appropriate NAU via a look-up table 534 and routes the message to that 
NAU. Since communications from the devices employ a variety of protocols, they are 
bundled into an IFE-message upon receipt from the physical device, and unbundled 
after receipt from the application services (via the NAU si. In this wav, the message 
processor 404 acts as a system translator. Using named pipes 535a and 535b, the 
message processor 404 receives messages from the NAUs. The message processor 404 
determines the appropriate device driver 531 and network address and routes the 
message to the device. As NAUs demand, the message processor 404 creates two 
named pipes 535a (input) and 535b (output! for each NAU, maintaining the table 534 
of pipe names (or handles) and their corresponding NAU IDs. The message processor 
404 logs invalid destination address errors. The message processor 404 registers with 
the system monitor 412 for coordinated system operation. 


25 


The detailed design of the Message Processor 404 will now be discussed. MP.EXE is 
the Message Processor and comprises the following files: 


ARCNTCLS . CPP 
ARCSMCLS.CPP 
DVCHNDLR.CPP 
MSSGPRCS.CPP 
PPPRCSSR.CPP 


The ARCNET interface Class 

The ARCNET Simulator Class for testing 

The Device Handler Class 

The Message Processor Class and MainO 

The Pipe Processor Class 
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SRLCLASS.CPP The Serial Driver Class 
WNRTTLCL.CPP The WinRTUtil Class 


ARCNTDRV.RT The ARCNET User-side Driver 
A Main 0 function used in the message processor 404 initializes its processing threads 


using StartHandlersO and PiveProcessorClassr.StartNA UThreadO functions. These 


threads operate continuously to move data from source to destination. MainO also 


registers its existence with the system monitor 412 program (usin 


MessaaeProcessorClass:Reaister()) and waits for a shutdown signal from the system 
monitor 412. after which it performs an orderly shutdown of all its threads. 

For each device driver 531. a Device Handler Class member is created. ArcnetClass 
defines Device Handler routines for the ARCNET driver 531a. The ARCNET driver 531a 
is a user side driver that performs the actual I/O with the ARCNET hardware. Because 
it is loaded along with the rest of the message processor 404, its interface is via 
Queue: :Put() and Queue: :Get() functions. SeriallOClass defines the Device Handler 
routines 532 for a serial device driver 531b. The serial driver 531b is a standard 
WINDOWS NT Serial Device Driver. ReadFileO and WRiteFileO are the functions used to 
communicate with it. All Device Handlers 532 in the Message Processor 404 provide 
the following capability. Two Input-Driven threads are provided to control I/O. The 
names vary from handler to handler, but these functions launch the infinitely looping 
threads that constantly wait for data to move between the device for queue! and the 
Message Processor 404. 


Handler 


Launch Function Name 


Thread Function 


Serial Device 


Seriallnvutlnterfacef 


MessaaeFromDriverfi 


SerialOutputlnterfacef 


MessaaeToDrivertt 


ARCNET 

Device 


MessaaeToHandlerThreadProcf 


MessaaeFromDriverfi 


MessaaeFromHandlerThreadProcf 


MessaaeToDriverf 


To receive data from the device drivers 531, MessaaeFromDriverfi 532a reads a 
message from its associated driver 531a or 531b using Get 0 or ReadFileO functions. It 
converts the input to a valid IFE Message using functions from the IFE Message Class 
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or ARCNET Message Classes. It then calls 

MessacieProcessorClass::MessaaeToPioeProcessorf i to add the message to the NAU 
Output Queue 538. 

To put data to an Output Queue 538, PutToHandler() puts a valid message at the end of 
the output queue 538 of its associated driver. It does not perform any data conversion. 

To output queued qata to a device driver 531, MessaaeToDriverO 532b reads the output 
FIFO queue 538 and issues the appropriate driver output command. It does not 
perform any data conversion. 

To start the handler to open communications to I/O ports, StartHandlerO performs the 
necessary initialization to get queues, pointers and driver connections ready. It then 
starts-up the two I/O threads {InPipeProcessorO 535a and OutPipeProcessorf) 535b). 

The term NAU Server means the set of routines that comprise a "server' 1 for the Network 
Addressable Unit processes. They are kept in the PipeProcessorClass. Two threads. 
NAUInThreadO and NAUOutThreadO are used to launch the set of I/O threads 
(InPipeProcessorO 535a and OutPipeProcessorf) 535b) for an as vet unknown NAU 
process. The first message received from any NAU registers it to this set of threads, 
causing NAUInThreadO and NAUOutThreadO to launch another set, getting ready for the 
next NAU to speak. In this wav, the Message Processor 404 is dynamic and can 
support different numbers of NAUs as needed. 

As for incoming messages. NAUInThreadO launches the InPipeProcessorO thread 535a 
which continuously receives a message from its input pipe 537b. If the message is 
meant to be routed to a driver 531, it gets sent to MessaaeToHandlerO 539b which 
places it on the appropriate driver's output queue 532c. If the message is meant to be 
routed back to an NAU, it is sent instead to AddMessaaeToOutOueueO 539a which 
performs this routing. 

As for outgoing messages, NAUOutThreadO launches the OutPipeProcessorO thread 535b 
which continuously reads a message from the NAU Out Queue 538 and sends it to its 
associated NAU process via its named pipe 537a. 
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Routers 537 are routines that use the LRU table 534 to determine which processing 
thread needs to process the message. One router 537 is a From-NAU Router. Upon 
demand, MessaaeProcessorClass::MessaaeToHandlerf) 539b moves the message to the 
appropriate handler. If necessary, it converts the message to the appropriate 'native' 
syntax using functions from IFE Message Class or ARCNET Message Class. It calls 
appropriate PutToHandlerf) function to move the converted message to the handler's 
output queue 532c. Another router 537 is a From-Device Router. Upon demand, 
Pit>eProcessorClass::AddMessacieToOutOueue() 539a calls the appropriate PutDatal } 
function to move the message to the NAU's output queue 538. 


10 The LRU table 534 is an internal memory structure which contains an entry for each 
device in the system 100. It contains sufficient information to translate message 
addresses from NAU-to-Driver and Driver- to-NAU, Specifically, it contains a physical 
name, which is the name of each device (e.g., 00 1A for seat 1A): NAU Type, which is the 
NAU that processes message (e.g., 7 corresponds to SeatNAUk Network Address fe.g.. 

15 4F040552 for seat lA’s seat display unit 122): and Device Handler that indicates which 

device driver 531 to use (e.g., 0 for ARCNET). This information is kept in a SOL 
database table which is read during the Message Processor Mainf) initialization via 
CreateLRUTabled 


As NAU processes register with the Message Processor 404, their identities are updated 
20 in this table via PipeProcessorClass::AddOueueInfoToLookUpTableO, 
PipeProcessorClass: : AddThreadPointeiToLookUpTableO and 

PipeProcessorClass::AddPipeHandleToLookUpTableO functions, which include Pipe 
Handle, Thread Class, Registeree, Queue Class, and Queue Semaphore. 

ARCNET is the token-passing network that provides the primary communication link 
25 between the Control Center and the backbone of the system 100. The ARCNET driver 
408 and 450 is software that provides the interface between the message processor 
404 and 452 and the physical ARCNET device interface in the cabin file server 268 or 
the primary access terminal 225. The desription below is for the primary access 
terminal 225. 


30 


For development efficiency, the ARCNET driver 408 has been attached to the message 
processor 404. The ARCNET driver 408 performs the following. The ARCNET driver 
408 obtains a network address of this line replaceable unit. The ARCNET driver 408 
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understands network addresses for up to 8 cabin file servers 268 and up to 8 primary 
access terminals 225. to provide for future growth. The ARCNET driver 408 initializes 
the ARCNET device to proper configuration. The ARCNET driver 408 signs-on to the 
network. The ARCNET driver 408 handles network reconfigurations and builds up 
network map to obtain information for routing messages across multiple ARCNET 
networks. The ARCNET driver 408 deals with transmit handshaking exceptions that 
may occur. 


The ARCNET device is an SMC CQM2Q020 Universal Local Area Network Controller, the 
same device as used in all backbone line replaceable units. The network speed is 1.25 
Mbps. The 256-bvte ARCNET packet (short packet format) is employed. A 2KB internal 
device RAM is divided into two 256-bvte pages: 1 receive buffer and 1 transmit buffer. 
The rest is currently not used. The line replaceable units are arranged in 2 ARCNET 
networks 216, one each supported by the primary access terminal 225 and the cabin 
file servers 268. The ARCNET driver 408 supports this variability. 

Figure 12 illustrates the operational flow of the ARCNET Driver 408. The ARCNET 
driver 408 is part of MP.EXE and comprises the following source file: ARCNTDRV.RT 
the ARCNET Driver Source. This file is pre-processed using WinRT (see the make file) 
to incorporate the necessary additional functionality. 

To use the ARCNET driver 408, a user first calls ArcnetDriverClass::StartDriverf) 601 to 
initialize this driver and its device and establish queues 607, 606 to be used to 
transmit and receive data. 


Figure 12 illustrates the operational flow of the ARCNET Driver 408, where StartDriverf) 
601 launches I/O (receive, transmit) threads 604, 605 and an interrupt handler 603, 
and StopDriverf) 602 shuts them all down. 

A discussion follows regarding the Network Addressable Units (NAU1 that reside on the 
primary access terminal 225. The primary access terminal 225 Network Addressable 
Unit program 409 function and data paths are shown in Figure 13. The primary access 
terminal NAU 409 provides the interface between the PAT GUI 426 or the Application 
Services and the unique devices attached to the Primary Access Terminal 225. Each of 
these devices is controlled via its own Virtual LRU (VLRU1 set of functions. In addition, 
most of these devices communicate via the same I/O channel, the PI Mux 402. The 
VLRUs are listed below. 
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Audio Tuner VLRU 
Card Reader VLRU 

GUI Monitor VLRU 

PAT VLRU 

Printer VLRU 


The Audio Tuner VLRU allows control of audio channel 
selections for flight attendant previewing via the PAT GUI. 

The Card Reader VLRU collects and forwards data from the 
card reader, to be used by the Access Functions and Sales 
Services 1 Functions. 

No LRU is actually associated with this VLRU. The GUI 
Monitor VLRU’s duty is to start the GUI and end the GUI 
as appropriate. 

The PAT VLRU responds to loopback messages from the 
CFS TestPort NAU via Ethernet for BIT functionality. It 
logs communication failures between the PAT and the CFS. 
It controls the BITE and COMM LEDs on the front of the 
PAT, lighting them to indicate failures. 


The Printer VLRU periodically queries the Control Center 
Printer for its status and provide this status as an 
unsolicited message to the PAT GUI. 



98-PS-039 







- 69 - 





- 72 - 


10 


15 


20 


25 


i 



- 73 - 



- 74 - 


10 


15 


20 


25 


i 



10 


15 


20 


25 


30 




10 


15 


20 


25 


30 





- 80 - 




82 - 


I 








- 88 - 


i 








■ 97 - 


i 















- 110 - 




- 112 - 



- 1 13 - 


5 


10 


15 


20 


25 






- 115 - 



10 


20 




PAT. EXE contains the primary access terminal NAU program 409 . In general, a 
network addressable unit program must first construct a NAUDispatch object and then 
construct one or more NAU objects, one for each virtual LRU fVLRUl that it supports. 
Certain VLRU-specific functions (such as NAU::StartItUpQ ) must be created for each 


VLRU type. The primary access terminal NAU program 409 includes the following 


primary components: 


PAT.CPP The Mainfi Program 
PDSPATCH.CPP The NAU Dispatcher 
GUMNITOR.CPP The GUI Monitor VLRU Class 
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CRDRDRVL.CPP 
TUNRVLRU.CPP 
PATVLRU . CPP 
PRNTRVLR. CPP 
PRNTRSTT. CPP 
PIMUX.CPP 
PINTRFCE . CPP 


The Card Reader VLRU Class 

The Audio Tuner VLRU Class 

The PAT main VLRU Class 

The Printer VLRU Class 

The Printer VLRU's Status Sub-Class 

The PI MUX VLRU Class 

The base class for the Tuner VLRU, Card 
Reader VLRU and PAT VLRUs 


Th e int e rnal int e rfac es of MainO registers with the s y s t e m 100 ar e d e pict e d in - Pigur e 
17. Th e sy s t e m 100 ha s Svstem Monitor 412 and launches a plurality of 
int e rfae es PIDispatch object to vid e o r e produc e r s 227. Each vid e o r e produc e r - int e rfac e 
5 is compri se d of - a vid e o input and a control int e rfac e . Th e s y s t e m 100 acc e pt s vid e o 
frem- open up communications between the message processor 404 and the transaction 
dispatcher 421. It calls PIDisvatch::startItUp() 518 to initialize the VLRUs. one each 
vid e o r e produc e r 227. Th e s y s t e m 100 acc e pt s vid e o in th e form of NTSG - c e mpo s it e 
vid e o, 1 volt p e ak - to - p e ak r- with - n e gativ e s ynchronization. Th e vid e o input provid e d . It 
10 also launches the Sessionf) threads 507. MainO waits to die, either by th e s y s t e m 100 
pr e s e nt s a 50 ohm imp e danc e , -s ingl e e nd e d. Th e sy s t e m 100 e mploys an RS -4 22 
int e rfac e to control th e vid e o r e produc e r 227. 


Th e s y s t e m 100 acc e pt s a maximum ^ of - 88 analog audio inputs. Th e audio inputs ar e 
use dreceiving a ProcessStop command from System Monitor 412, or else it sleeps 
15 forever until interrupted. It calls shutltDownf) 518a to r e c e iv e audio data from audio 
r e produc e r s (AR) 123 compri s ing th e audio tap e r e cord e r s 123, pr e r e cord e d boarding 
music, pas se ng e r addr e ss audio, or oth e r s ourc es of audio programming. All audio 
input s ar e standard balanc e d inputs complying close all the VLRUs down w ith 
RTCA/DO 170, e xc e pt th e s ignal l e v e l is 0 dBm or 0.775V into a 600Q load. a 
20 SubProcessStop command and exit gracefully. 


Th e audio - vid e o s e at di s tribution unit 231 ha s int e rfac e s us e d Referring to 
communicat e with th e pa sse ng e r control unit s 1 - 2 - 1 controll e d - by - t - hat audio - vid e o s e at 
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Field 


C h a ract e ri s tic s D es cription 


Ma s t e r 
Phon e ABB 


Non e , ADB1 Sp e cifi e s which ABB s e rv e s as 

DB8. Ma s t e r in th e Phon e Loop. 


Phon e Diff e r e ntial Y es /No. 
Input 


Indicat e s wh e th e r th e phon e input 
io diff e r e ntial or not. 


Phon e Conn e ction Non e , ADB1 
O rd e r B B&r 


Up to 8 ADBs may - b e dai s y 
chain e d in th e phon e loop. 
Conn e ction ord e r - is s p e cifi e d h e r e . 


Th e ACS - t e ol - provid es th e us e r th e capability to modify ADB di s cr e t e information for a 
s p e cifi e d ar e a di s tribution box 217 . Each ar e a - di s tribution box 217 has two input and 
two output di s cr e t e s. Th e modifiabl e fi e lds ar e d e fin e d b e low. 


Field 


Charact e ri s tic s 


Description 


Input Discr e t e 1 


^ Not Us e d', 'Air/ Ground 1 , 
'PA Ov e rrid e * or 'MC 
R e s e t'. 


S e l e ct from th e list to d e fin e 
discr e t e input #1 for th e 
s p e cifi e d ADB. 


Input Di s cr e t e 2 


^ Not U se d' , 'Air / Ground' , 
- PA Ov e rride' or 'MC 
R e s e t'. 


S e l e ct from th e list to d e fin e 
di s cr e t e input #2 - for th e 
s p e cifi e d ADB. 


Output Di s cr e t e 1 'Not Us e d' 


Not U se d. 


Output Di s cr e t e 2 'Not Us e d' 


Not U se d. 


5 


For - configuration s d e fin e d with an aircraft typ e of 7 4 7 200, th e ACS tool pr o vid e s th e 
capability to d e fin e se at lamp assignm e nts for a sp e cifi e d -se at row and se at l e tt e r. Th e 
modifiabl e fi e lds ar e d e fin e d b e low. 
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217 and OEB Column, th e ACS tool allows th e us e r to indicat e , for th e se l e ct e d 
ov e rhead -e l e ctronie s box, what oeat row and column ID it s e rv e s, and th e r e ading lamps 
and row call lamp s for which it provid es outputs. Th e modifiabl e fi e lds ar e d e fin e d 
b e low. 
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± llilU 

Characteristics 

ASIF 

4- 

S 

Starting Seat Row 

0 - 

-99 

Ending Seat Row 

0 - 

-99 

Starting Seat 
Letter 

A- 

—L 

Ending Seat Letter 

A- 

-L 

ASIF Location 

Selection- for ADB 
1 to ADB 8. 


D es cription 

Id e ntifi e s which ASIF th e sp e cifi e d 
ADB int e rfac e s with. 

1st s e at row in th e zon e which th e 
ASIF provid e s s e rvic e for. 

L a s t se at row in th e zon e which 
th e ASIF provid es s e rvic e for. 

1 s t se at l e tt e r in th e zon e which 
th e ASIF provid e s se rvic e for. 

Las t s e at row in th e zon e which 
th e ASIF - provid es se rvic e for. 

Id e ntifi es which ADB is to 
int e rfac e with th e sp e cifi e d ASIF. 


Th e ACS tool provid e s - th e capability to d e fin e th e display controll e r se ttings informa tion 
fe r -^a p to 20 zon e s. Each zon e i s capabl e of containing 12 uniqu e di s play controll e r 
d e finition s . For a sp e cifi e d rang e of s e ats/row s , th e us e r may d e fin e a r e solution of th e 
touch s cre e n (if ap p licabl e ), th e tim e- out of th e IR s e nsor (if e nabl e d) and th e d e fault s of 
th e brightn es s and volum e . 
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Fiekl Charact e ri s tics D es cription 

fceft Int e g e r from 1 to 90 In d icat es th e tim es lot of th e l e ft audio 

s carc e for th e giv e n chann e l. 

Right Int e g e r from 1 to 90 Indicat e s th e tim es lot of th e right audio 

sourc e for th e giv e n chann e l. 

Th e ACS tool provid es th e capability to d e fin e vid e o sourc e information. Th e actual 
numb e r of chann e l s mad e availabl e to e ach pa s s e ng e r d e p e nds on th e configuration 
d e fin e d in th e databas e . Th e- audio chann e l s ar e th e sam e throughout th e aircraft. 
Th e r e ar e a maximum of 2 4- vid e o program s availabl e that may us e up to 32 vid e o audio 
chann e ls (for mult i- languag e capability) and 2 4 vid e o chann e ls. Th e modifiabl e fi e lds 
ar e- d e fin e d b e low. 
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Languag e 3 


Two fi e ld s of 
int e g e rs - from 0 to 


Indicat e s th e fr e qu e ncy at which th e l e ft 
and right 6 t e r e o audio from th e vid e o 
s ourc e is to b e broadcast for Languag e 3. 


Languag e 4 


Two fi e ld s of 
int e g e r s from 0 to 


Indicat e s th e fr e qu e ncy at which th e l e ft 
and right -ste r e o audio from th e vid e o 
sourc e i s to b e broadcast for Languag e 4 . 


Th e ACS tool provid es th e capability to d e fin e th e audio chann e l information. For a 
s p e cifi e d zon e , th e u se r may id e ntify th e PCU display chann e l numb e r, th e audio sourc e 
chann e l, and wh e th e r th e s ourc e is an audio chann e l, vid e o languag e 1, or vid e o 
languag e 2. Th e modifiabl e fi e lds ar e d e fin e d b e low. 


Field 


Charact e ri s tic s D e scription 


PCU Di s play 


T e xt s tring of two Indicat es what chann e l numb e r th e PCU 
ASCII charact e rs, di s play indicat es for this audio chann e l. 


D e fault 


Y e s(X)/No(Blank). Indicat es wh e th e r or not this audio is th e 
d e fault for th e PCU display. 


Audio Sourc e 


T e xt string of two 
ASCII charact e rs. 


In - conjunction with th e Sourc e d e finition, 
Indicat e s which audio chann e l i s to b e 
mapp e d to this PCU di s play chann e l. 


Sourc e S e l e ction of: Audio Indicat es th e sourc e of th e audio to b e 

Sourc e , Vid e o a ss ign e d to thi s display chann e l. 
Languag e 1, Vid e o 
Languag e 2. 


5 


Th e ACS tool provid e s th e capability to d e fin e th e in - s e at vid e o chann e l arrang e m e nt 
information. For a sp e cifi e d zon e , th e us e r may id e ntify th e PCU di s play chann e l for an 
id e ntifi e d vid e o sourc e , indicat e wh e th e r th e chann e l is pay or fr ee , and which languag e 
(of tho se d e fin e d f o r - th e vid e o s ourc e ) is assign e d to th e chann e l. Th e modifiabl e fi e ld s 
ar e d e fin e d b e low. 
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continuou s s e ating ar e as which mak e up a singl e zon e . Th e modifiabl e fi e ld s ar e 
d e fin e d b e low. 
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dispatcher (TD) 421 communicate by way of a Network Addressable Unit (NAU) 

5 dispatcher 500 that comprises NAUDispatch. NAUDispatch is a base class that 

contains the code necessary to open a framework for a new Network Addressable Unit. 
It contains the following global objects: 

Qpair MP_Fifos Qpair MP_Fifos keep track of traffic between the 
NAU and the Message Processor. The NAU Object 
Ids are stored in these two queues. 

Qpair TD_Fifos Qpair TD_Fifos keep track of traffic between the 
NAU and the Transaction Dispatcher. The NAU 
Object Ids are stored in these two queues. 

Queue RunlmmediateFifo The Queue RunlmmediateFifo keeps track of 

NAUs which require immediate attention, 
regardless of outside messages. 

Queue TimedOutFifo The Queue TimedOutFifo allows an NAU VLRU to 

time out, thus giving processing over to others 
until the time out occurs. 

Queue DestructFifo The Queue DestructFifo is used by shuiftDown() to 
cause each VLRU to shut down. 

Queue AuxFifo The Queue AuxFifo is used in Session. cpp of 
Seat.exe only. 

Only the first constructor call per program uses InitNAUDispatch() to start all session 
threads 507 (one for each VLRU plus 2 up to a maximum of 14) for the NAU. It opens 
10 | Named Pipes 51 9519a and 519b between the message processor 404 and the 

transaction dispatcher 421 Fifos 501, 502 and the session threads 507 to manage I/O 
between them. It then initiates threads 511-514 that manage input and output 
between the message processor 404 and the transaction dispatcher 421 (MPLeftQ 511, 
MPRightQ 512, TDLeftQ 513 and TDRightQ 514). Once these initialization steps have 
15 been accomplished, the main program constructs NAU state machine objects 510 (also 
called VLRUs). 

In addition, this class contains the following utility functions: 
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AdcLNAUQ This routine adds a VLRU object ID to an array for 
later lookup (to send it a message or shut it down, 
for example). 

AddNAUMapQ This routine adds a VLRU object ID and its text 
name to an array for later lookup. 

FindNAUQ Returns the VLRU object ID based on the text name 
passed to it. 

GetNthNAUQ Returns the VLRU object ID in the ’nth’ position in 
the array. 

GetNumberOfNAUsQ Returns the number of VLRU object Ids in the 
array. 

RemoveNAUFromMapQ This routine removes a VLRU object ID and its text 

name from the array. 

SendToAUVLRUsQ This routine sends the same message to all VLRUs 
via their MPRight.queue, as if it was sent via the 
MP. It uses MP logic as a short-cut, rather than 
developing more routines for intra-process 
communication. 

SendToOneVLRUQ This routine sends a message to a single VLRU via 
its MPRight.queue, as if it was sent via the MP. It 
uses MP logic as a short-cut, rather than developing 
more routines for intra-process communication. 

shutltDownQ This routine is used to turn off all VLRUs, typically 
called because a message was sent by the System 
Monitor to the main() routine to do so. 

startltUpf) The startltUpQ routine is used to start up all 
VLRUs. 

The MPRight() Thread routine 512 continuously waits for incoming messages from the 
Message Processor 404 via the Named Pipe 519a. The term 'right' indicates that the 
data moves from left-to-right in Figure 3813. 

The MPRightQ Thread 512 uses the IFE Message Class routines to deal with the data 
5 received. Once a message is received using IFE_Message::GetData(), it looks up the 
appropriate VLRU name (!FE_Message::GetAddress() ) and uses it to look up the 
appropriate NAU object ID (FindNAUQ ). Then it stores the incoming message in that 
NAU's MPQueue. Right queue 516a and places the NAU's ID into the Dispatcher's 
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MP_Fifos. Right queue (MPPutNAUQ ) 501. This ID is then used by the Session threads 
507 that are constantly running to decide which VLRU needs to be processed. 

A "hook" function pointer is provided with this thread to allow applications to pre- 
process the message prior to MPRight()'s storage. If no hook function is defined, this is 
5 ignored. 


| The MPLeftO Thread routine 511 continuously waits for outgoing messages for the 
Message Processor 404. The term "left" indicates that the data moves from right- to-left 
in Figure 3813. It uses the IFE Message Class routines to deal with received data. 

Using Queue::Get() it reads the NAU ID from the MP_Fifos.Left queue 501 then uses 
10 that NAU's MPGetNAUQ function to read the data from its MPQueue.Left 517a, and uses 
I IFE_message::PutData() to output the message via the Named Pipe 5 19b. 


15 


20 


25 


30 


The TDLeftH Thread 513 behaves like MPRiaht Ofl 512. except that the input comes from 
the Tran s action Di s patch e r 4 2 l transaction dispatcher 421 . The TDRiahtfl Thread 514 
behaves like MPLeftf hO 511. except that the output goes to the Transaction 
Di s patch e r transaction dispatcher 421. 

It is sometimes impractical for all VLRUs to be running at once (for example, the seat 
NAU can contain more than 500 VLRUs), so a maximum number of processing threads 
has been established as 14. These threads 511-514 each execute a SessionQ function 
507 which waits for an event such as input from any source (message processor 404, 
transaction dispatcher 421, TimeOut, etc.), then determines which VLRU state machine 
needs to be run to process the message and executes it via the VLRU’s StartltUpQ 
function 518 called by NAU::EntryPt(). When EntryPtQ returns, the message is fully 
processed, and SessionQ 507 loops to get another one. 

The NAU class contains foundation routines and data for any VLRU. It is derived from 
the timed Callback class and Cobject class (from a C++ Foundation Class Library). The 
NAU constructor makes an object that has TDQueue and MPQueue, two Qpair objects. 
These queues are used to store the actual data or IFE_Message needed by the VLRU 
state machine. The NAU constructor also creates three Event Semaphores, including a 
RunlmmediateEvent semaphore, a TimeOutEvent semaphore and an AuxEvent 
semaphore, which allow it to control processing via the related Queues in the NAU 
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dispatcher 500 . Finally, the NAU constructor creates one mutex, DispatchMutex which 
coordinates which Session thread can access the data for a given VLRU (in case two 
threads try to handle messages for the same VLRU). 

The StartltUof I function 518 (not the same as NAUDispatch::startItUp() ) is called by 
5 NAUDispatch::Session() when a message is ready to be processed by the VLRU. The 

StartltUpfl function 518 typically varies per VLRU, but it's job is to fully process one 
message received from any source. That may simply mean passing the message on, say 
from message processor 404 to transaction dispatcher 421 or vice-versa. 

Data Movement Functions will now be discussed. The NAU class contains the following 
1 0 members used to move data to and from the message processor 404 and the 
transaction dispatcher 421 : 

MPGetNAUQ Moves data from MPQueue.Left for output to the MP. 

MPPutNAUf) Moves data from input from MP to MPQueue. Right. 

NAUGetMPQ Moves data from MPQueue. Right into StartItUp() for processing. 
NAUGetTDQ Moves data from TDQueue.Left into StartItUp() for processing. 
NAUPutMPQ Moves data from StartItUp() into MPQueue.Left for later output. 
NAUPutTDf) Moves data from StartItUp() into TDQueue. Right for later output. 
TDGetNAUQ Moves data from TDQueue. Right for output to the TD. 

TDPutNAUQ Moves data from input from the TD to TDQueue.Left. 

Other generic NAU functions include: 

bOKToRunQ Reports to NAU Dispatch whether a VLRU is ready 
to run. The base version of this always returns 
TRUE. 

EntryPtQ This launches the VLRU's own StartltUpf) 
function. 

get_hTimeOutEvent() Returns the value of the Time Out Event handle. 

get_hVLRUEvents() Returns a pointer to all the Event Handles used 
by this session to get Input. 
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get_NAUState() Returns the current state of the VLRU. If "Active", 
the VLRU is capable of processing information. If 
"Inactive", it can't take any messages. For 
example, if the system is not currently allowing 
game play, the HSDL VLRU would be "Inactive". 

GetBJTEStatus() This function varies from VLRU to VLRU and is 
only a placeholder in the base class. 

GetMPQPairQ Returns a pointer to the MP Queues - lets the 

user bypass the entire message traffic philosophy. 

GetNameQ Returns the text name of the current NAU VLRU. 

GetTDQPairQ Returns a pointer to the TD Queues - lets the user 
bypass the entire message traffic philosophy. 

GetUseMessageCounterQ Retrieves a flag set with SetUseMessageCounterQ. 

set_NAUState() Used to control the state of the VLRU state 
machine. Currently, the two states used are 
"Active" and "Inactive". 


SetUseMessageCounterQ Sets a flag used by NAUDispatch::SessionQ. If 

TRUE, SessionQcounts messages for the VLRU. 
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obiects 510 functions discussed in conjunction with Figure 13. Most of these devices 
communicate via the same I/O channel, a PI Mux. 

The tuner VLRU allows control of audio channel selections for flight attendant 
previewing via the PAT GUI 426, The TunerVLRU class is also a PHnterface class child. 
Its StartltUvO routine handles the SubProcessStart and SubProcessStop commands the 
same as the others, and then waits for I/O from either the PI Mux or the transaction 
dispatcher 421. If a message is received from the PI Mux, it forwards it to the 
transaction dispatcher 421 using NAU::NAUPutTD(L If a message is received from the 
message processor 404, it forwards it to the PI Mux using ToMuxPutO . 

The card reader VLRU collects and forwards data from the card reader 12 Id, to be used 
by the access functions and sales services* functions. Based on the PHnterface class, 
the CardReaderVLRU class is the first actual VLRU created for this NAU. It creates an 
event called StartEvent which is used by PIMux to coordinate all the other PHnterface 
VLRUs. Its StartltUvO 518 routine loops forever retaining its SessionO thread. It looks 
for a SubProcessStart command from the message processor 404 (which is issued by 
NAUDisvatch::startItUvO) and then waits for StartEvent to trigger before processing any 
other messages. Once StartEvent has occurred, it can continue processing. If it 
receives a SubProcessStop message, it terminates. It reads and ignores all other 
messages from the message processor 404 and the transaction dispatcher 421. 

Instead, it looks for input via its From Mux semaphore event, which tells when it has 
received data from the PI Mux. If the PI Mux sends a CardRead command, this VLRU 
calls MaaCarcLDataO to process this message. All other messages are returned to the 
Mux via the ToMux queue. MaaCardDataf) converts the data into ASCII and forwards it 
to the primary access terminal application via the transaction dispatcher 421. 
Optionally for testing, the Register can be set with the value "DisplavMagCardData' 1 to 
cause all the card data to be printed to a window at the primary access terminal 225 
via stdout. 


The GUI Monitor VLRU starts the GUI and ends the GUI as appropriate. No LRU is 
actually associated with this VLRU. When the GUI Monitor object is created, it creates 
an extra event called ServiceAlive. This event is set via ServiceMonitorO and tested in 
StartltUvO 5 IS to know whether Cabin Service is communicating to this NAU. The 
StartltUvO routine is called as soon as all the VLRUs are created via the 
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PIPisvatch::startItUD() it launches another thread called ServiceMonitorO which 
continuously tries to receive messages from the Cabin Services program via a mail slot. 
It then uses this as a 'heart beat* to know if the application is still alive. If this heart 
beat fails to occur after having been established, the GUI Monitor terminates the GUI 
process. If this heart beat is never established, ServiceMonitorO simulates one, for test 
purposes. StartltUvf) 518 continuously loops and waits for the SubProcessStart 
command from the message processor 404 (from the PIDispatch::startItUp() routine), 
and then it waits for PEHsvatchf) to tell whether it connected to the database 
successfully by triggering the ConnectedToService event. Then it attempts to start the 
CGUI.EXE program. If StartltUvf) detects that the GUI terminated, it attempts to restart 
it. StartltUvf) ignores messages from the transaction dispatcher 421, and only 
processes the SubProcessStart and Stop commands from the message processor 404. 

The Card Reader, Tuner, PI Mux, primary access terminal and Printer VLRUs are all 
based on the PHnterface class. Essentially, this provides support for one more source 
of I/O, from the PI Mux (or multiplexed I/O port) via the PIMux VLRU. The PIMux 
VLRU provides the following member routines: 


ARCNTCLS . CP P ToMuxPutf) Th e ARCNET int e rfac e Cla ss Converts a 

PAT Message into appropriate syntax for either 
Audio Tuner or PI 'Board* message and sends 
the data to the ToMux queue. 

ARCSMCLS . CP P FromMuxPutft Th e ARCNET Simulator Cla ss for t e6 tin g Places 

a message on the From Mux queue. 


SVCHNDLR. CP P FromMuxGetn Th e D e vic e Handl e r Cla ss Reads a PI Message 

from the FromMux queue and converts it to a 
PAT Message. 


MSSGPRCS.CP P ToMuxGetf) Th e M es sag e Proc es sor Clas s and Mam fl Reads 

and encodes for transmission a PI Message 
from the ToMux queue. 


PPPRCSSR.CP P FromMuxSemavhor 

eHandlef) 


Th e Pip e Proc es sor Cla ss Retums the handle for 
this queue 


SRLCLASS. CP P FromMuxSemavhor 

eHandlef) 


Th e S e rial Driv e r Cla ss Retums the handle for 
this queue. 


The PIMux class is the VLRU which communicates via the message processor 404 and 
the transaction dispatcher 421 for all I/O with the PI Board, for card reader, tuning. 
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etc. The PIMux class points to each of these VLRU classes for data transfers through 
their FromMux and ToMux queues. A StartltUpf) routine loops forever retaining its 
Session 0 thread. It looks for a SubProcessStart command from the message processor 
404 (which is issued by the NAUDispatch::startItUp() routine) and triggers the 
5 StartEvent to activate its associated VLRUs (Card Reader, etc.]. 

Once StartEvent has occurred, it proceeds to receive I/O from the message processor 
404 and the transaction dispatcher 421. It determines which sub- VLRU should 
process the message and forwards it to their FromMux queue for handling, and then it 
responds an Ack or Nak to the PI board, as applicable to satisfy its communications 
10 protocol needs. 


Messages from the VLRUs intended for the PI Mux are sent to this VLRU as well via 
their ToMux queues. It encodes the messages as needed, forwards them and handles 
the Ack/Nak protocol. It has its own version of NAUGetMPf) in order to use the 
PI Message data handling routines. 


15 


20 


25 


30 


The primary access terminal VLRU responds to loopback messages from the CFS 
TestPort NAU via Ethernet for BIT functionality. It logs communication failures 
between the primary access terminal (PAT) 225 and the cabin file server fCFSl 268. It 
controls the BITE and COMM LEDs on the front of the PAT, lighting them to indicate 
failures. The PatVLRU class is also a PHnterface class child only so it can synchronize 
operation via the StartEvent trigger. Its constructor reads the registry 
’'VerbosePATVLRLr settings (for test purposes) and the "BITTestlntervaT value for BIT 
testing timeouts. StartltUpf ) launches a thread called BitTestMonitorf) and then loops 
continuously to process messages. First, it waits to receive a SubProcessStart message, 
then it waits for the StartEvent to know that PIMux is alive and ready to go. 
SubProcessStop causes it to kill the BitTestMonitorf) thread and then die. All other 
messages from the message processor 404 are ignored. If an Ethernet Loopback 
message is received from Test Port NAU via the transaction dispatcher 421. it uses 
EthemetLoopbackO to return a message via NAU::NAUPutTD(L and then tell the 
BitTestMonitor that the loopback occurred. All messages from the PIMux are returned 
to it via PlInterface::ToMuxPut() and otherwise ignored as an error. The BitTestMonitorf) 
turns both BITE and COMM LEDs on at the primary access terminal 225 to show that 
they are both working. Then it turns off the BITE light and waits. If it receives 
notification from StartltUpf) that a loopback occurred, it turns off the BITE LED. If it 
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times out waiting for a loopback, it turns the LED back on. If it gets several successive 



provides this status as an unsolicited message to the PAT GUI 426 . The PrinterVLRU 
object is a PHnterface class child only so that it can sync up with PI Mux to start 
processing. Its constructor retrieves " Printer PollIntervaT and '^rinterStatusTimeout" 
from the Registry and then creates hEventPrinterStatusChange and hEventStop to 
communicate to the monitor thread that is created in StartltUofl This class also has a 
PrinterStatus class object called Printer which does all the actual communication with 
the printer over the Ethernet network 228 . StartltUpf) launches the 
PrinterStatusMonitorf) thread, and then loops forever. The only message processor 
messages it processes are: 


ocessStart signal to continue 


cessStoi 


receipt it waits for the StartEvent 


the Monitor thread and dies 


thr e ad s u s ing Start - Handlers O StartltUpf ) ignores all messages from the transaction 
dispatcher 421 . It echoes any messages back to the PI Mux and 
Pip e ProeessorGlass::StartNAUThread() function s- . - Th ese thr e ad s op e rat e continuously 
mov e data from sourc e otherwise ignores them. If StartltUvf) receives a PrinterStatus 
event (from the monitor), it calls SendPrinterStatusf) to d es tination. Mainf) also r e gist i 


lild the status message and : 


sends it to the CAPI Message Service via NAUr.NAUPutTDO. PrinterStatusMonitorf) uses 
the PrinterStatus object of all its thr e ads. 
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provid e d to control I/O. Th e nam e s vary from handl e r this VLRU to handl e r, but th e s e 
functions launch talk to the printer. If it cannot talk to the infinit e ly looping thr e ad s 
t hat - con s tantly wait for data to mov e b e tw ee n printer via 

PrinterStatus::InitializePrinterSNMP(). it logs the d e vic e (or au e u e l and error to the event 
log. If changes in the printer status occur, it tells StartltUpQ via 

hEventPrinterStatusChange. It logs the following other events to the event log: Out of 
Paper. Has Paper Again, any other errors, and 1st Status after any error. 

SendPrinterStatusO uses PAT Message Proc ess or 4 0 4 : 

Handl e r Launoh Function Nam e 

S e rial D e vic e SeriaUnputlnterfaceQ 

S e rialOutputlnterfaceQ 

ARCNET MessageToHandlerThreadProc() 

D e vic e 

MessageFromHandlerThreadProcO MessageToDriverQ 

To r e c e iv e data from th e driv e r 53 l,MessageFromDriverQ 532a r e ad s a m e s s ag e from 
its associat e d driv e r 531 using GetQ or ReadFileQ functions (for e xampl e ). It conv e rt s 
th e input to a valid IFE rou tines to convert the PrinterStatus info to ASCII. It then 
sends it on to the CAPI Message u s ing functions from th e IFE_M e ssag e- Gla ss or 
ARCNET_M e ssag e Clas se s. It th e n calls 

M e ssageProcessorClass::MessageToPipeProcessorQ to add th e m es sag e to th e NAU 
Output Qu e u e 536. 

To Put Data to an Output Qu e u e 536. PutToHand l erft put s a valid m es sag e at Service 
via NAJJr.NAUPutTDO. The PrinterStatus class constructor connects to the e nd of th e 
output qu e u e 536 of it s a ss ociat e d driv e r. It do e s not p e rform - any - data conv e r s ion ? 

T e- Qutput-Qu e u e d -Da ta to Printer via the Ethernet network 228 using 
InitializePrinterSNMPfl, requests the Driv e r 5 3 1. MessageToDriverQ r e ads status via 
ReauestRawPrinterStatusfi. Interprets (with StatusDescriptionfl 1 and displays the output 
FIFO qu e u e 5 3 6 and issu es th e appropriat e driv e r output command. It do e s not 
p e rform any data conv e rsion, printer status info using DisnlauPrinterStatusO. among 
other private routines. 


Thr e ad Function 

McssagaFromDriv e rQ 

MessageToDriverQ 

Messag e FromDriverQ 
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25 I Mail Slots 553, a Services Server 554, and Service Clients 555. The NAU Server 552 
comprises a plurality of OutPipeProcessorsQ 552a, a plurality of InPipeProcessors() 
552b, and a plurality of NAU Out FIFO Queues 552c. A plurality of Name Pipes 556 
couple the NAU Clients 551 to the InPipeProcessors() 552b and OutPipeProcessors() 

552a and InPipeProcessors() 552b. The NAU Out FIFO Queues 552c are respectively 

S 

i 
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coupled to the OutPipeProcessorsQ 552a. The Services Server 554 comprises a 
plurality of OutPipeProcessors() 552a, a plurality of InPipeProcessors() 552b; and a 
plurality of Service Out FIFO Queues 552d. The Service Out FIFO Queues 552d are 
respectively coupled to the to the OutPipeProcessors() 552a. A plurality of Name Pipes 
5 556 couple the Service Clients 555 to the OutPipeProcessorsQ 552a and 

InPipeProcessors() 552b. 

The Router and mail s lot s Mail Slots 553 comprises the LRU table 53 4553a , which is 
coupled to an AddMessageToOutQueue() 557. The InPipeProcessors() 552b of the NAU 
Server 552 are coupled to the AddMessageToOutQueue() 557. Also, the 
10 InPipeProcessors() 552b of the Services Server 554 are coupled to the 

AddMessageToOutQueue() 557. The AddMessageToOutQueueQ 557 is coupled by way 
| of a IntraNodal Output Queue 553 4553b to an IntraNodalOutThreadProcessorQ 558a. 
The IntraNodalOutThreadProcessorQ 558a is coupled to any process on any NT line 
replaceable unit connected by way of the Ethernet network 228. Similarly any process 
15 on any NT line replaceable unit connected by way of the Ethernet network 228 to an 
IntraNodallnThreadProcessorQ 558b is coupled to the AddMessageToOutQueueQ 557. 


20 


The primary duty of the Transaction Dispatcher 421 is to move information between 
the logical devices (or NAU sNAU clients 551) and the Application Services for service 
clients 5551 . By using a Transaction Dispatcher 421, the NAUs and the Services do not 
have to control I/O traffic. In addition, the number of Named Pipes (or communication 
lines) between processes is greatly reduced because each Service and NAU need only 
communicate with one process, rather than each other. This simplifies the software 
design and efficiently uses a finite number of available Named Pipes. 


To support this, the transaction dispatcher 421 includes the following sub-functions. 

25 Upon demand, the transaction dispatcher 421 creates two Named Pipes (input and 

| output) for each NAU and Service, maintaining the lookup table 534 553a of pipe names 
(or handles) and their corresponding NAU or Service IDs. 


The transaction dispatcher 421 uses Blocking I/O to await a message from any 
incoming Named Pipe. Once it receives an IFE-structured Message, it examines only 
30 the message destination (NAU or Service ID) portion of the message to identify the 

I appropriate Named Pipe to use by cross-referencing the lookup table 53 4553a . It then 


\ 
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| routes the complete message to an output queue 553 552c and 552d for that Named 
Pipe. 

The transaction dispatcher 42 1 uses Mail Slots to send and receive messages from 
processes that are resident on remote Window s WINDOWS NT line replaceable units, 

5 routing them to the appropriate destination. Using this technique, any Service or NAU 
can communicate with any other Service, NAU or program on this line replaceable unit 
or any line replaceable unit that also runs a transaction dispatcher 421. 

The detailed design of the transaction dispatcher 42 1 will now be discussed. Figure 
| 3Q14 illustrates the transaction dispatcher function and data paths. TD.EXE is the 
10 transaction dispatcher 421 and is comprised of the following file: 

TRNSCTND.CPP - the Main Program and TransactionDispatcherClass 

The MainQ function of the transaction dispatcher 42 1 is responsible for initializing all 
its processing threads using CreateMainServiceThreadsQ, CreateMainNAUThreadsQ and 
CreateMainlntraNodalThreadsQ functions. These threads operate continuously to move 
15 data from source to destination. 

MainQ also registers its existence with the system monitor program 412 (using 
RegisterQ) and waits for a shutdown signal from the system monitor 412, after which it 
performs an orderly shutdown of all its threads via its destructor. The relationships of 
the transaction dispatcher functions are shown in Figure 3Q14. 

20 The term NAU Server means a set of routines that comprise a "Server" for the Network 
Addressable Unit processes. Two threads, NAUInThreadProcessorQ and 
NAUOutThreadProcessorQ are used to launch a set of I/O threads ( InPipeProcessorQ 
552b and OutPipeProcessorQ 552a) for an as yet unknown NAU process. The first 
message received from any NAU registers it to this set of threads, causing 
25 NAUInThreadProcessorQ and NAUOutThreadProcessorQ to launch another set, getting 
ready for the next NAU to speak. In this way, the transaction dispatcher 421 is 
dynamic and can support different NAUs as needed. 

With regard to Incoming Messages, InPipeProcessorQ 552b continuously receives an IFE 
Message from its Input Pipe and sends it to AddMessageToOutQueueQ 557 which routes 
30 it to the appropriate output queue. With regard to Outgoing Messages, 
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OutPipeProcessorQ 552a continuously reads an IFE Message from the NAU Out Queue 
552c and sends it to its associated NAU process via its named pipe 556 . 

The term Services Server 55 5554 means the set of routines that comprise a "Server" for 
Cabin and Sales Services. Two threads, ServicelnThreadQ and SeruiceOutThreadQ are 
used to launch a set of I/O threads (InPipeProcessorQ 552b and OutPipeProcessorQ 
552a) for an as yet unknown Service process. The first message received from any 
Service registers it to this set of threads, causing SermcelnThreadQ and 
SeruiceOutThreadQ to launch another set, getting ready for the next Service to speak. In 
this way, the transaction dispatcher 42 1 is dynamic and can support different Services 
as needed. 

With regard to Incoming Messages, InPipeProcessor() 552b continuously receives a 
message from its Input Pipe and sends it to AddMessageToOutQueueQ 557 w hich routes 
it to the desired output queue. As for Outgoing Messages, OutPipeProcessorQ 552a 
continuously reads a message from the Service Out Queue 552d and sends it to its 
associated Service process via its named pipe. 

The router 553 comprises routines that use the lookup table 5S4 r553a to determine 
which processing thread needs to process the message. With regard to the From Any 
Source Router, upon demand, AddMessageToOutQueueQ 557 calls the appropriate 
PutDataQ function to move the message to the NAU or Service output queue. 

The Nam e d Pip e LRU Lookup Table 55 4553a is an internal memory structure that 
contains an entry for each device in the system 100. It contains sufficient information 
to translate message addresses for any piped destination. Specifically, it contains: Pipe 
Handle, Registeree, Queue Pointer, Queue Semaphore, and Thread Pointer. 

_This information is kept in an SQL database table which is read during the MainQ 
initialization via CreateLRUTableQ . Then as piped processes register with the 
transaction dispatcher 421, their identities are updated in this table 55 4553a via 
AddQueuelnfoToLookUpTableQ , AddThreadPointerToLookUpTableQ and 
AddPipeHandleToLookUpTableQ functions. 

Tabl e Nam e CSV Nam e 
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\ 


| LRU LRU 

The term Intra Nodal Server means the set of routines that permit communications 
| between two Windows WINDOWS NT line replaceable units connected via the Ethernet 
network 228. This differs from the Named Pipe communications in that a set of 
communication pipes is not created and maintained for each process. Instead, a single 
5 mail slot is maintained for incoming messages, and an appropriate outgoing mail slot is 
created for each outgoing message as needed. 

With regard to Incoming Messages, IntraNodaUnThreadProcessorf) 558b continuously 
receives a message from its Mail Slot and sends it to AddMessaaeToOutOueuef if) 557. 
which routes the message to the appropriate destination. The destination may be an 
10 NAU, a Service or even back out to another process via a mail slot. With regard to 

| Outgoing Messages, IntraNodalOutThreadProcessorQ 558a continuously reads a message 
from its Out Queue and sends it to its associated process via the Mail Slot. This mail 
slot is created for just this message, and then is closed after the message is sent. 

The System Monitor program 412 is automatically invoked by the operating system 
15 when the line replaceable unit boots. The system monitor function and data paths are 
shown in Figure 3415. The System Monitor program 412 comprises a service_main() 
561 that is coupled to a StopServicesQ 566 565 . The System Monitor program 412 is 
coupled to console services 562 by way of a ConsoleInput() 562a. Other outside testing 
| processes 562a 562b are coupled to a service_cntrl() 563. A WatchDogDrive 56 7591 
20 along with the service_cntrl() 563 and the ConsolelnputQ 562a are coupled to a 
MainQueue 564. 


25 


30 


A Process/ Event Lookup table 567 is coupled to a GetSystemFullActionItemn() 568 that 
interact with a serv_server_main() and server_main() 565 566 . The MainQueue 564 is 
coupled to the server_main() 56 5566 . The MainQueue 564 is coupled to a 
ProcessEventListQ 569. The ProcessEventList() 569 is driven by a plurality of Sysmon 
Class and Process Class State Machine Functions 570a, 570b. Output of the Process 
Class State Machine Functions 570b are coupled to OutputQueues 571 of various 
Process and Process I/O functions 572, 572a. The Process and Process I/O functions 
572, 572a are coupled by way of OutputLoop() 573 and Name Pipes 574 to the 
transaction dispatcher 40 4421 and message processor 421404. The transaction 
dispatcher 404 -421 and message processor 421 404 are coupled by way of Name Pipes 
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574 to respective InputLoop() 575. The respective InputLoop() 575 are coupled to the 
MainQueue 564. 


5 


Sorted functions of the Process Class State Machine Functions 570b are coupled by 
way of a QueueSorted Queue 576 and a StatPutQueueThread() 577 to the MainQueue 
564. Additional runtime processes 578 are also coupled by way of Name Pipes 574 to 
SysmonConnectThreads() 579. The SysmonConnectThreads() 579 are coupled by way 
of a Register: :RegisterInput() 580 to the Process functions 572. 


10 


A WatchDogDrive 591 is provided that comprises a WatchStaticThread 592, a 
DogQueue 59 2593 and a StatQueueThread 594. The WatchStaticThread 592 outputs 
to the DogQueue 59 2593 and a PExtemalKillProcess() from the Process Class State 
Machine Functions 570b are coupled to the DogQueue 59 2593 . The DogQueue 
592 593 outputs to the StatQueueThread 594 which in turn drives the WatchDog 
Driver 410. 


The System Monitor program 412 operates in the background during the life of the 
1 5 control center applications and has the following four basic duties: 


Start-Up The Start-up function starts the Executive and Application 
programs after any system boot. 

Shutdown The Shutdown function provides an orderly shutdown, flushing 
working data from memory to hard disk as appropriate. Then it 
terminates the execution of the Executive and Application 
programs. 


Power Down This function works in conjunction with the Uninterruptable 

Power Supply (UPS) 400 which is connected via one of the serial 
ports on each of the Control Center LRUs. The operating system 
is notified by the UPS when power has been lost, causing it to 
start this function (POWERDWN.EXE, POWERDWN.CPP). The 
Power Down program notifies the System Monitor that power has 
been lost to invoke an orderly shutdown using a 'ProcessStop' IFE 
Message. POWERDWN.EXE is listed in the NT Register as the 
program to start when power failure is detected. 


Restart The Restart function scans for failed Executive and Application 
programs, and restarts them. 


The detailed design of The System Monitor 412 will now be discussed. 


SYSMON.EXE includes the following primary components: 
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SYSMON.CPP The MainQ Program and Sysmon Class 

DLYSCHDL.CPP The Delay Scheduler Class 

PROCESS. CPP The Process Class to manage the external programs 

QUEESORT.CPP The QueueSort Class - Used to manage sorted queues 

RGSTRBJC.CPP The Register Class used to register external processes 

SMSCRIPT.CPP The SysmonScript Class to manage the state tables 

SYSGLOBA.CPP Global routines to map to state-machine functions 

SYSMNCNN.CPP The SysmonConnect Class used to communicate 
externally 

SYSMNSPC.CPP SysmonSpecial Class 

UTL150.CPP RandomPack and Liner Classes plus other utilities 

WTCHDGDR.CPP The WatchDogDrive Class 

Referring to Figure 34-15. the System Monitor 412 is a Windows NT Sendee Process, 
which means it runs in the background and is controlled by the following functions in 
the Win32 SDK Library: StartSendceCtrlDispatcherf), ControlServiceQ, HandlerQ, 
RegisterSreviceCtrlHandlerf), and SendceMainQ. 

5 The System Monitor 412 was designed as a state machine, but, it's actual code is more 
of an in-line design with state flags used to keep track of processing. For example, a 
single function calls another function which calls yet another function, and all three are 
only used once. For clarity, these are grouped together herein. 

The main() function updates its revision history information in the Windows W INDOWS 
10 NT Register, determines where to find the other programs to be started, launches itself 
as a Window s WINDOWS Service by connecting to the Window s WINDOWS Service 
Control Manager via StartSendceCtrlDispatcherQ, identifying sendce_main() 46 4561 as 
the main function for this service. The main() function is identified in advance of 
runtime during software installation, which calls the NT CreateSendce() to set up the 
15 System Monitor 412 as a Window s WINDOWS NT Service. Main()also alters its behavior 
depending on whether a Consol e d e vic e 4 62 console service 562 (i.e. , a display monitor) 
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is available for testing. Main() uses SetConsoleCtrlHandlerQ to allow someone to abort 
the programs by pressing Ctrl-C at any time. 

Sermce_main() 46 1561 is the matin program that continually runs when the system 
monitor service is running. It calls RegisterServiceCtrlHandlerQ to identify sermce_ctrl() 

5 | 46 3563 to NT as the function to execute when other outside programs want to alter the 
execution of this service. It maintains a combination state-checkpoint to identify to the 
outside world (i.e., test programs) what it is doing: 

State Checkpoint(s) Service Control Code to get 

there 

SERVICE_START_PENDING 1,2 (none) 

SERVICE_RUNNING 0 Service_Control_Continue 

SERVICE_PAUSED 0 Service_Control_Pause 

SERVICE_STOP_PENDING 0, 1 Service_Control_Stop 

SERVICE.STOPPED 0 (none) 

When service_main() 561 starts, it is in SERVICE_START_PENDING state, checkpoint 
#1. If it successfully creates all its event handles, it moves to checkpoint #2. It then 
10 | sets up a Security Descriptor and launches a serv_server_mcdn() thread, moving its 
state to SERVICE_RUNNING. 

The outside world can alter its state by calling service_ctrl() 563 and providing a Service 
Control Code. The table above shows which state service_main() 561 moves to based 
| on the control code received. If the SERVICE_STOPPED state is reached, an 
1 5 hServDoneEvent is triggered, causing this function to exit, terminating the System 

Monitor 412. 

The service ctrlO 563 routine is called via an NT Service utility ControlServiceQ by any 
outside program that wishes to control the System Monitor service in some way. 
Service_ctrl() 563 uses a MainQueue 564 to issue commands to various Process Class 
20 objects that are running. 

The Serve r server mainO 566 routine creates the Sysmon object MainSysmon and 
executes its Sysmon:: StartHandlerQ to get the other processes running. If running in 


98-PS-039 



-251- 


test mode, server mainfl 56 4566 is called directly by mainQ. If ru n n ing in runtime 
mode, server_main() is called by serv_server_main() 565 -566 w hich is a thread launched 
by sermce_main() 561 (the main program initiated by the Window sW INDOWS NT Service 
Manager). Finally, server mainf) 566 calls Sysmon::MainQueueProcessing() which loops 
5 until it is time to shutdown. Once MainQueueProcessingO returns, this thread ends. 

The StopServiceQ function 566 -565 can be used by any thread to report an error and 
stop the Sysmon Service. It logs the reason that it was called via ReportEventQ, and 
tells service_main() to abort via hServDoneEvent. 

_Derived from Process, the Sysmon Class contains all the software needed to drive all 
10 the Process Class state machines. It uses MainQueue 564 as its primary input. 

Sy smon: : St art Handler () is responsible for launching all the external programs and 
providing a means to monitor them. First, it compiles the file SYSMON.ASC. Then, it 
queries the NT Registry to determine which type of line replaceable unit it is running on 
(PAT, CFS or test unit) to know which processes to initiate. It creates a SmScript object 
15 to establish system- level state machine tables using SmScript: :InitiateTables(). It sets up 
communications with the UPS 400 via a communication port, and determines whether 
the UPS 400 is working, whether the line replaceable unit has power and whether it 
should continue processing as a result. Finally, it creates the following objects and 
runs a starter function for each of them: 


Object 

Class 

Starter Function 

ConnectTask 

SysmonConnects 

StartHandlerConnQ 

MyWatchDog 

WatchDogD river 

StartHandlerQ 

ProcessItem[i] 

Process 

InitializeQ 

(one for each 
process 


(StartHandlerQ is called later, after 
Process Registration) 

for this LRU) 



SelfHeartBeatTask 

SysmonSpecial 

StartHandlerSpecialQ 

SelfMonitorTask 

SysmonSpecial 

StartHandlerSpecialQ 

DelayTask 

DelayScheduler 

StartHandlerDelayQ 
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QueueSorted QueueSort None, used to schedule events (i.e., 

Process: :PPostExtemalKillProcess () ) 

It creates an EventOnQueue object with an UpSystem event in it and places it in the 
MainQueue queue 564 to start the external processes (beginning with the Transaction 
Dispatcher 421). Finally, it calls Sysmon::MainQueueProcessing() which loops forever, 
using Sysmon::MainProcess() to handle all processing requests which get placed on the 
5 MainQueue queue by this and the other classes' threads. 

The basic flow of startup events is: 

UpSystem Event from Sysmon::StartHandler start Transaction 

Dispatcher 

Registration received from Transaction Dispatcher start Message Processor 
Registration received from Message Processor start Service 

Registration received from Service start NAUs 

In this way, the system comes up in a sequential, orderly fashion. 

MainQueueProcessingO loops forever waiting for Events to appear on the MainQueue 
queue. Once found, it calls MainProcess() which uses the information from the 
10 EventOnQueue object to lookup the 'real' action(s) to perform using the 

SmScript::GetSystemFullActionItem() and Process: :GetTotalMatrix() functions. It 
processes these actions using Sysmon::ProcessEventList() 567569. 

ProcessEventListQ 567 569 is only called by MainProcessQ to look up and process the 
desired actions from a table of actions, which are maintained in the SmScript Class. 

15 The above processes loosely form a state machine. In fact, a series of flags denoting the 
state of the Sysmon system is used to decide what to do next. The following routines 
| are used to support this state machine. Curr e ntly. th e r e T here is only one system level 
Action List to do: UpSystem[] or UpPAT[]. They each have several Actions which point 
to SYSGLOBAL functions. These functions in turn determine whether they should call 
20 a Process class function or a Sysmon class function. The Sysmon Class functions are: 

PSysSoftRebootQ Calls softbootQ which uses the ExitWindowsExQ command 
to reboot the LRU. Called via the global PSoftRebootQ 

{ 


98-PS-039 



-253- 


function. 

| PSysHardRebootQ Reboot -via W atchDogDriver::Watch_Reboot() which causes 

the hardware to reset. Called via the global PHardRebootQ 
function. 

PSysGetStateQ Retrieves the state of the system state machine. Called 
via the global PGetProcessStateQ function. This is not 
used: The variable ’selfstate' is used directly. 

PSetSysStateQ Sets the state of the system state machine, which is used 
in GetSystemFullActioriltemQ along with the current event 
to know what action to do to the system. Generally called 
via the global PSetStateQ function. 

The SysmonConnects class contains code necessary to communicate to the other 
processes in the line replaceable unit, for example the Transaction Dispatcher 421. It 
establishes a Named Pipe set to communicate with each of them. It works very closely 
with the RegisterObject Class to provide pipes to each of the Process Class handlers. 

5 This method of creating a generic Named Pipe set and assigning it to the first process to 
register was taken from the Transaction Dispatcher 421, however, because this 
program directs which external process is executed, and therefore which one is 
registered. 

The StartHandlerConn() routine simply launches two threads, one for Named Pipe Input 
10 and one for Named Pipe Output. 

InputConnectThreadQ is launched by StartHandlerConnQ . It calls DynlnputQ which loops 
forever, opening a Named Pipe for input, then waiting for an outside process to connect 
to it. It then creates a temporary RegisterObject class object to tie this Named Pipe to 
the connecting outside process, and loops to create another named pipe. 

15 OutputConnectThreadQ is launched by StartHandlerConn(). It calls DynOutputQ which 
| loops forever, opening a Named Pipe 574 for output, then waiting for an outside process 
to connect to it. It then creates a temporary RegisterObject class object to tie this 
Named Pipe to the connecting outside process, and loops to create another named pipe. 

When the DynlnputQ and DynOutputQ routines of SysmonConnect receive input from an 
20 outside process to claim a Named Pipe, they create a temporary RegisterObject class 
object to receive Registration information from the calling process and tie the current 
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Named Pipe to the Sysmon Process object associated with that process. In this way, 
each Process object has its own set of I/O to its corresponding external process. 

This launches RegisterlnputQ as a new thread. It is called by both 
SysmonConnects::DynInput() and DynOutputQ. The Registerlnput() code calls 
5 DynRegisterlnputQ and kills itself and its SELF (its own object) when DynRegisterlnputQ 
is done. The DynRegisterInput() routine tries to read from the Named Pipe to get a 
Registration message from the outside process. It attempts this 100 times before it 
gives up and exits. If successful, it calls Process: :StartHandler() to get its Input or 
Output thread started with this Named Pipe. 

10 The SmScript Class contains the tables of events and actions that are used to move 
each Process object state machine from one state to the next. FullActionltem arrays 
read like pseudo code, each entry containing the following set of information: Function- 
Name, Process ID, Additional Data for the named Function. Thus, for example, 
, '{PHardReboot,systemflag,150}" means to run global function PHardReboot(150), which 
15 in turn runs the system function Sysmon: :PSy sHardRebootf 150). 

The InitiateTables() routine is called once per power-up to prepare the event/ action 
table SysMatrix as appropriate for the runtime LRU system monitor. It fills this array 
with a pointer to the UpSystem or UpPAT FullActionList array. 


20 


25 


The InitProcess() routine is called by Process: :Initialize() for each process object created 
to complete the tables for the Process to use. It moves the appropriate event/ actions 
into this Process object’s TotalMatrix array. This permits the use only one System 
Monitor executable program, even though its specific duties vaiy from line replaceable 
unit to line replaceable unit-tfa r. For example, the primary access terminal LRU does 
not have the Service process and the File Server LRU does not have the primary access 
terminal NAU process). 


The GetSystemFullActionItem() routine returns the appropriate value from the 
SysMatrix table. The is used only in Sysmon: :MainProcess(). 


The Process Class InitializeQ initializes the TotalMatrix table via SmScript: :InitProcess(). 
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The Process Class StartHandlerQ is called by RegisterObjectr.DynRegisterlnputQ after an 
external process has successfully registered with Sysmon. It calls StartlnputThreadQ or 
StartOutputThreadQ depending on the Named Pipe which was registered. 

StartlnputThreadQ is called by StartHandlerQ and simply launches a new thread, 

5 InputLoopQ. InputLoopQ in turn simply calls DynlnputLoopQ for this process. 

DynlnputLoopQ continuously loops, collecting any IFE Message, from its Named Pipe 
(using the IFE_Message::GetDataQ function), and processing it using ProcessIncomingQ. 
Errors are reported using ProblemReportQ and the MainQueue is updated to control 
either a shutdown or retry, depending on the severity of the error. If it's error is severe 
10 enough, it exits the loop and the thread dies. 

StartOutputThreadQ is called by StartHandlerQ and simply launches a new thread, 
OutputLoopQ. OutputLoopQ in turn calls DynOutputLoopQ for this process. 
DynOutputLoopQ continuously loops, collecting any IFE Message from its OutputQueue 
and sending it out its Named Pipe (using the IFE_Message::PutDataQ function). Errors 
15 are reported using ProblemReportQ and the MainQueue is updated to control either a 
shutdown or retry, depending on the severity of the error. If it's error is severe enough, 
it exits the loop and the thread dies. 

GetTotalMatrix()retums the corresponding Action List from TotalMatrix for the current 
event and state of this process. It is called only by Sysmon: :MainProcessQ. 

20 The following State Machine routines are stored in the SmScript State Machine Tables 
(called FullActionltems) and are activated as a result of certain event/ state 
combinations via ProcessEventListQ: 

PExtemalKillProcessQ Kills its associated external process with the 

TerminateProcessQ function. Called from the 
global PExtemalKillProcessQ function. 

PGetProcessStateQ Returns the current state of this state-machine. 

Called from global PGetProcessStateQ. 

PKillProcessQ Issues IFE message to external process to commit 
suicide. Currently not supported by most external 
processes. Called from global PKillProcessQ. 
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PPostExtemalKillProcessQ Uses the QueueSortedr.PutSortedQ function to 

schedule a Kill command to go into the MainQueue 
later. Called from global PPostExtemalKillProcessQ. 

PSetStateQ Updates the current state of this state-machine. 
Called from global PSetStateQ. 

PStartProcessQ Gets the full pathname of the associated external 
process and starts executing it. Called from global 
PStartProcessQ. 


10 


15 


The WatchDogDriver class contains code necessary to manage watchdog driver 
messages. The watchdog is a hardware component that is responsible for re-starting 
the line replaceable unit if it fails to receive input in regular intervals. Using this class 
ensures that the watchdog receives that input from the System Monitor 412 regularly, 
unless some system or software error prevents it. Commands available for use by 
Sysmon and Process objects are: Watch_EnableQ, Watch_DisableQ, Waich_MaintainQ 
and Watch_RebootQ. These functions gill put the corresponding watchdog action 
command onto a DogQueue 468593 for processing by DynQueueThreadQ, which is the 
only function allowed to actually talk to the driver directly. 


The Watchdog Driver 410 controls a watchdog device supplied by Octagon (called the 
Octagon PC-4501 which, when activated by the System Monitor 412 . reboots the system 
unless it is accessed no less than every 1.6 seconds by the watchdog driver 410 . The 
driver 410 can receive a command to force a reboot of the system, which stops it from 
updating the watchdog driver 410 , The watchdog driver 410 then times-out and a 
reboot occurs. Use of the watchdog driver 410 helps improve system availability in the 
event of a software or hardware anomaly that causes unpredictable results in system 


operation. 


Sysmonr.StartHandlerQ creates the WatchDogDriver object and calls its StartHandlerQ 
routine, which is responsible for launching two threads. One thread manages the I/O 
with the watchdog hardware, and the other thread maintains the regular output 
commands to it. 


WatchStaticThreadQ calls WatchDynamicThreadQ which places a request for a 'strobe' to 
the watchdog onto the DogQueue 46 8593 (viaWatch_MaintainQ ). It then sleeps for 
1,000 seconds and loops again. 
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StatQueueThreadf) calls DynQueueThreadQ which performs the actual output to the 
watchdog hardware, "\wdog". It reads a command request from the DogQueue queue 
46 8593 and calls either Watch_Enable_DO(), Watch_Disable_DO(), Watch_Maintain_DO() 
or Watch_Reboot_DO() to perform the requested command using the Window s W IND O W S 
DeviceloControlQ function. 

The QueueSorted Class coordinates activity in the MainQueue 46 4564 . For example, it 
is sometimes necessary to schedule tasks to occur in the future (such as shutdown due 
to loss of power). To do this, QueueSorted provides the following functions. The 
QueueSorted() constructor creates its own queue and launches a thread, 
StatPutQueueThread() to monitor the queue periodically. The PutSorted() function 
allows users to add elements to the queue along with a timestamp indicating the time 
at which this element should be dealt with. The PutSorted() function puts them on the 
queue sorted by the timestamp so that they are dealt with in the proper order. 

StatPutQueueThreadQ calls DynPutQueueThreadQ which loops forever, trying to process 
the elements on its queue. If the current time is less than or equal to the time of the 
element's timestamp, the element is moved to the MainQueue for processing by 
Sysmon::MctinQueueProcessing(). Even though it is scheduled, it is only placed at the 
end of MainQueue 46 4564 . not at the front. Therefore, it does not supercede any 
existing MainQueue elements. 

The following common software libraries of functions and utilities are used throughout 
the primary access terminal 225 and cabin file server 268 applications. 

Utility Library - UTILITY. LIB 

Th e Databa se Utiliti e s, DB UTILS. CPP ar e commonly us e d by all databas e applications. 
Th e y us e th e SQL - command s (r e cognizabl e as starting with db...(f, s uch as dbexitQ, 
dbresultsQ, e tc.): 

The CAPI (RPC Client) Library 427 . or RPCLIENT.DLL 427 . provides a means of 
communication between the graphical user interface 426 and the rest of the system 
100 through the primary access terminal NAU 409 . The RPC Client Library 427 is 
shown in Figure 16. The RPC Client Library 427 . or RPCLIENT.DLL 427 . comprises a 
ToExec Queue 770 . a FromExec Queue 771 . a FromGUI Queue 772 , and an 
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APIINT::CMSToGui Queue 773. The ToExec Queue 770 and FromExec Queue 771 are 
coupled to transmit and receive CGUIService::ProcessRequestf) threads 775. The 
FromGUI Queue 772 is coupled to transmit various APIINT.CCP calls 782 to the 
CGUIService::ProcessReauestn threads 775. The APIINT.CCP calls 782 are derived 
from CAPI C.C Calls 783 that are routed by wav of the Ethernet network 228 from 
CAPI S.C calls 784 in the Services.exe program 477 running in the cabin file server 
268. The CGUIService::ProcessRequestO threads 775 route messages to and from a 
local transaction dispatcher 421a. The APIINT::CMSToGui Queue 773 receives 
messages from the local transaction dispatcher 421a and from a remote transaction 
dispatcher 421b. Messages sent from the transaction dispatchers 421a, 421b. are 
forwarded to an APIINT::CAPIMessageInThreadProcedureO: 785 which routes the 
messages to the CAPI Message Service Window 781. 

The PAT GUI 426 cannot be communicated to via Named Pipes because it is a 
WINDOWS application, and must therefore communicate using standard WINDOWS 
messages. The CAPI Message Handler is a set of routines within the CAPI Library 427 
which provides a bridge between the IFE messages and the GUI WINDOWS application. 
Instead of communicating via Named Pipes directly with the GUI, Unsolicited Messages 
780 utilize Named Pipes into a Message Service Window 781. In order for the GUI 426 
to be able to receive them, it must have already opened or started a Window capable of 
receiving this type of message in the background using the appropriate CAPI Library 
calls. 


Any WINDOWS User Interface that needs to communicate with the transaction 
dispatcher(s) 421 of the primary access terminal 225 and/or cabin file server 268, or 
who needs to access the CAPI calls in the SERVICE.EXE program of the cabin file 
server 268 needs to link in and use the RPCLIENT.DLL library 427 which contains the 
following files: 


Funotio n APIINT. CPP Purpo s e DUmainf) and Visual Basic Application Interface 

Routines 


Continuou s ly loop s- calling dbresultsQ to g e t th e results 
of th e prior SQL call - for this proc e ss until th e y hav e all 
b ee n obtain e d. If th e r e ar e e rrors, it di s play s - function 
t e xt - for tracing. T he CAPFs RPC Client Support Routines 


UodateStats O HOOKSPL 

L.C 


Updat e s th e stati s tic s of th e giv e n tabl e for th e giv e n 
proc e s s . 'Canned* Dynamic Link Library 'glue' from 
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Purpo se 

Copi e s th e- Cu s tom e rNam e data into the 
t FE^M e ssag e data. 


Copi es th e ExpirationDat e data into th e 
I FE^M ess ag e data. 


Formats a s a dollar amou - nt - and copi es 
Amount into th e IFE_M es 6ag e data. 


Writ es th e valu e in wBuildld to th e Databas e 
Build ID fi e ld po s ition in th e IFE_M ess ag e 
data. 

Format s e laps e d tim e 0 — 999 into 
IFE_M es sag e data. Valu es gr e at e r than 999 
ar e r e duc e d to 999. 


C opi es th e High Sp ee d Download Qu e u e 
Status into th e IFE_M e ssag e- data. 


Copi es th e IFE Stat e valu e into th e 
IFEjVf es sag e data. 


Copi es th e M ess ag e Id - into th e IFE_M es sag e 
data. 


S e t s th e l e ngth of th e IFE_M ess ag e data 
bas e d on th e raw - data m e ssag e l e ngth. 

Copi e s th e M e ssag e sProc e s se d into th e 
I FE ^ M e ssag e data. 
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APPIINT.CPP is the interface between the graphical user interface 426 (GUI or Main 
Application) and the rest of the system 100 . In order to connect to the rest of the 


system 100. InitializelnterfaceVBn must be called to establish communications with the 
transaction dispatcherfs) 421 and start CAPI Message Service: :GetTDInMessaaef) 
threads, which receive all unsolicited messages from the transaction dispatcherfs) 421 . 
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A call to StartMessaaeServiceVBf) launches a thread, CAPMessaaelnThreadProceduref) 
to continuously read and process unsolicited messages obtained from the CMSToGui 
Queue, supported by the CAPI Message Service class object. 


5 


The cabin file server 268 and the primary access terminal 225 have many similar 
functions such as message processors 404 and 452, transaction dispatchers 421 and 
473, system monitors 412 and 454, and ARCNET drivers 412 and 450. The 
discussion of these functions in conjunction with the primary access terminal 225 
presented above also applies to the cabin file server 268 with differences as noted. The 
cabin file server executive extension is discussed with reference to Figure 10. 


10 The cabin file server Executive Extension set of routines together with the Common 
Executive Software forms the generic application for the cabin file server 268. It 
includes the following components: Backbone NAU 463, Seat NAU 465, VCP NAU 462, 
Test Port NAU 461, High-Speed Download Driver 449, Services 477 including Cabin 
Services 478-482, 487-490 and Sales Services 483-486, CAPI calls 476, and the 
15 database 493, as shown in Figure 10. The function and data paths of the many of the 
NAUs 461-465 have a structure substantially identical to the primary access terminal 
225 structure shown and described with reference to Figure 10 regarding the basic 
network addressable units function and data paths. The changes generally relate to the 
structure of the state machine objects that are used in the respective NAUs 461-465, 


20 


25 


30 


The detailed design of the cabin file server executive extension will now be discussed. 
The BACKBONE.EXE routine contains the backbone NAU program 463. Figure 17 
illustrates the backbone NAU program 463 function and data paths. The backbone 
NAU 463 is responsible for receiving and processing messages that originate from the 
audio-video units 231, area distribution boxes 217, passenger entertainment system 
controllers PESC-A 224a and the PESC-V 224b, and any other communications 
backbone line replaceable unit. The structure of the backbone NAU 463 is 
substantially the same as the network addressable unit 409 function in the primary 
access terminal 225 and data paths discussed with reference to Figure 13. The 
backbone NAU 463 comprises a PESC-V NAU dispatcher 500a and PESC-V and PESC- 
AP VLRU state machine objects 510a shown in Figure 17. The backbone NAU program 
463 includes the following primary components: 


BACKBONE. CPP The Main() Program 
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PSCPDSPT. CPP The NAU Dispatcher for the PESC-A 

PSCVDSPT.CPP The NAU Dispatcher for the PESC-V 

PSCPVLRU. CPP The VLRU Class for the PESC-A 

PSCWLRU. CPP The VLRU Class for the PESC-V 


The MainQ program is a standard NAU starter that registers the Backbone NAU 463 
with the system monitor 442 454 using a SysMonInterfaceClass::RegisterQ routine. 


5 


The Main() program launches a PescV_Dispatch object to open up PESC-V VLRU 
communications between the message processor 404 452 and the transaction 
dispatcher 42 4473 . and a PescAp_Dispatch object as well to launch the PESC-A 224a. 
It calls PescV_Dispatdv:startItUp() to initialize both of the VLRUs (sinc e th e y'r e both 
BackBon e NAU s , this works) . 


The MainQ program launches 14 SessionQ threads, although only three are actually in 
use. It sends a SubProcessStart command to the VLRUs which causes the first 
10 SessionQ threads in to connect to each VLRU permanently. Only the PescV_Dispatch 
object maintains a set of MPRightQ, MPLeftQ, TDRightQ and TDLeftQ threads. 


Finally, the MainQ program sleeps forever until interrupted. It does not call 
shutltDownQ to close all the VLRUs down and exit gracefull y - (thi s ha s b ee n comm e nt ed 
©«t). Instead, it simply deletes the PescV_Dispatch object and dies. 

1 5 The VLRUs in this NAU contain their own set of NAUPutTDQ, NAUPutMPQ, NAUGetTDQ 
and NAUGetMPQ routines because they use I/O routines from the PESCA_Message class 
and PESCV_Message class instead of the IFE_Message class. 


The PescAp_VLRU object attaches directly to the first SessionQ possible via its StartitUpQ 
| function. Then T it continuously loops waiting for data to appear in its message 
20 processor and transaction dispatcher input queues. It processes the following 
commands: 


FlightlnfoRequest IFE Function from the PESC-A 224a. This VLRU creates its own IFE 
message to the IFE Control Service asking for Flight Information. 
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FlightlnfoUpdate IFE Function from the IFE Control Service, after the PESC-A 224a 
issues it a FlightlnfoRequest. This VLRU creates its own IFE message to forward this to 
the PESC-A 224a via the message processor 40 4452 . 

PES_CONTROL command from the PESC-A 224a. This VLRU examines the state of the 
5 WeightOnWheels using PESCA_Message::IsGearCompressed(). If the state of the wheels 
has changed, it forwards this new information to the database using 
Notify NewFlightStateQ, and to the CAPI Message Service via its own NAUPutTDQ. 

_A11 other messages are ignored. 

This prints to th e standard output (if any) a s ingl e charact e r to d e not e progr e ss: 

Charact e r M e aning 

? Unknown Command or M e ssag e 

PES_Control_Command r e c e iv e d 
V W e ight ON Wh ee ls 

A W e ight OFF Wh ee ls 

10 The PescV_VLRU object attaches directly to the first Sessionf) possible via its StartltUpQ 
function. Then, it continuously loops waiting for data to appear in its message 
| processor 452 and transaction dispatcher 473 input queues. It processes the following 
commands: 

VideoControl command from IFE Control Services is formatted and forwarded to PESC- 
15 V 224b. Any other message from PESC-V 224b is routed directly to the IFE Control 
Services. This prinfc s- to - th e s tandard output (if any) a -s ingl e charact e r to d e not e 
progr e s s : 


Charact e r M e aning 

} Unknown Command from th e m e ssag e proc ess or 

J? Unknown Command from th e transaction 

di s patch e r 

< Y 4 d e oControl Command R e c e iv e d 
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| The Seat NAU program 465 function and data paths are depicted in Figure £518. The 
Seat NAU 465 controls communication with the seats in the aircraft 111. It maintains 
three kinds of VLRUs: one that controls high speed download of games and programs to 
the seats 123; one that periodically broadcasts status messages to the seats 123, and 
5 one for each seat 123 to communicate during the flight for sales and other requests. 

The structure of the Seat NAU 465 is substantially the same as the Network 
| Addressable Units function and data paths discussed with reference to Figure 3813. 
However, the Seat NAU 465 also includes VLRU state machine objects 510b comprising 
an HSDLInterface VLRU 650, a Seatlnterface VLRU 651, and a SeatBroadcast VLRU 

10 652 . 

The HSDLInterface VLRU 650 comprises a ProcessFileChanges() 650a, 
ProcessDownloads() 650b, and a RefreshThread() 650c. The Seatlnterface VLRU 651 
comprises a Crank() 651a, a SessionQueueLeft 651b, and a SessionQueueRight 651c. 
The SeatBroadcast VLRU 652 comprises a PendingSessionMonitor() 652a and a 
15 WheelStatusMonitor() 652b. 

SEAT.EXE contains the Seat NAU program 465. This program includes the following 
primary components: 

NAUMAIN.CPP The Main() Program 

HSDLDSPT.CPP The High Speed Download NAU Dispatcher 

STDSPTCH.CPP The Seat NAU Dispatcher 

STNTRFCE.CPP The Seat VLRU Class 

SESSION. CPP The Service Session Class 

STBRDCST. CPP The Seat Broadcast VLRU Class 

HSDLNTRF. CPP The HSDL VLRU Class 

DWNLDFLN. CPP For HSDL, the DownLoadFilelnfo Class 

FILEMAP.CPP For HSDL, The FileMap Class 

A VLRU Session is characterized by the NAU::Session() threads, one for each VLRU that 
| may be active concurrently. A Service Session is characterized by the Session class 7 
20 that controls a stream of communications between a single seat and a Service (such as 
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a Sales Service). This stream may include several messages back and forth before a 
Service Session is complete. 

The Main Program is a standard NAU starter. MainQ registers this program with the 
System Monitor 454 using the SysMonlnterfaceClass: .Register () routine. For test 
purposes only, if any parameter is passed to this program, it bypasses this step. 

The Main Program creates a HDSLDispatch object to open up communications between 
the message processor 40 4452 and the transaction dispatcher 421473 and create the 
High Speed Download VLRU 650 . Then the Main Program creates the SeatDispatch 
object to create all the Seatlnterface VLRUs 651 and the SeatBroadcaster VLRU 652 . 
The Main Program launches 14 SessionQ threads 507 that are shared by all the VLRUs. 
A typical number of Sessions is 14 including 10 seats' Service Sessions, plus HSDL, 
plus Broadcast, plus two more to control seats that are waiting for a Service Session to 
free up (pending seats). The Main Program calls NAUDispatch::startItUpf) 518 to 
initialize the VLRUs with a SubProcessStart command. 

The HSDLDispatch file defines a MPRightHookQ function to be called within the 
NAUDispatdv:MPRight() thread prior to processing the incoming message from the 
message processor 40 4452 . It uses this hook function to intercept the High Speed 
Download Request messages and route them to the HSDL VLRU 650 instead of to the 
Seat VLRU 651 , where its LRU address would normally send it. This reduces traffic to 
the 10 Sessions 0 507 reserved for the seats. 

Finally, MainQ sleeps forever until interrupted. It does NOT not call shutItDown() to 
close all the VLRUs down and exit gracefully (thi s has b ee n comm e nt e d out) . Instead, it 
simply deletes the NAU Dispatch and dies. 

The Seatlnterface VLRU 651 is responsible for processing requests from the seats 123 
such as ordering a movie or a game. It routes these requests to the applicable Service 
via the Transaction Dispatche r 473 . One VLRU for each seat 123 in the system exists 7 ; 
however, only 10 VLRUs at a time may actively be engaged in a communication session 
between seat 123 and Service. 

Each Seatlnterface VLRU 651 has a Session object that it uses as its state machine. 

Its StartltUpQ function loops continuously as long as it is actively engaged within a 
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session (that is, the session state is not idle), looking for one of the following events: 
Data from the message processor 40 4452. Data from the transaction dispatcher 
424473, an NAU TIMEOUT, an NAU RUN IMMEDIATE, a NAU AUX, a 
SessionQueue.Right or SessionQueue.Left events. It passes any TD messages on to the 
5 | seat display unit 43 3122 provided they do not affect the State of the VLRU. StartltUpQ 
then calls Session: :Crank() to process one event from the SessionQueue.Right queue. 
Once it has been processed, StartltUpQ forwards any message that may be waiting in 
SessionQueue.Left (sending it out to the message processor 40 4452 or transaction 
dispatcher 424473), then determines what to do with the input event that got it going 
10 (from the message processor 40 4452 . transaction dispatcher 424 473 . Timeout etc.). 
Usually, it simply puts it in SessionQueue.Right, which re-triggers StartltUpQ to again 
call Session: :CrankQ until all events and/or messages are processed. Once the 
processing is complete for this VLRU's Session, StartltUpQ exits, to give the session 
thread to another seat. It uses MessageToEventQ to convert a Seat_Message into its 
15 corresponding Event value, and it uses EventToMessageQ to develop an appropriate 
outgoing message based on the current VLRU Event. 

StartltUpQ also processes the following control messages: 

IPE Message Action 

StartStatisticsCapture Sent by the SeatBroadcast thread when 

WeightOnWheels is detected, uses 
timedCallbackr.queueQ to set a timer to a random value 
to cause the Statistics request to go to the seat after 
the timeout. This prevents all seats from processing 
the request at the same time (as it would from a 
broadcast), to keep the traffic on the network less 
congested. 

SubProcessReinit Re-Initializes tables via InitializeQ. 

SubProcessStart Starts the State Machine for this VLRU, putting it into 

the Start state. 

SubProcessStop Exits. 

Se rvio e Sess ion Cla ss 

At a minimum, a seat transaction requires sending a message to a S e rvie e service 477 
20 and receiving an answer back. However, if it is a complex transaction (for example, a 
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multiple-product merchandise order), several messages are routed before the entire 
transaction is complete. Because 500 seats 123 mav be all communicating at the same 
time, the basic design of communications flow from the seat 123 to the S e rvic e s services 
477 and back can get highly fragmented when these complex transactions are involved. 

5 To minimize this fragmentation (and thus create the appearance of faster response at 
the seats), the Service Session protocol has been developed. 

Supported by the Session class and the SDU interface, this protocol requires a seat 123 
to open a session (or tap dibs) with the Seat NAU 465 before a transaction can take 
place. Only 10 Sessions 507 are supported simultaneously (controlled in the Session 
10 constructor by hSessionSemaphore), so if they are all busy, a Pending message is 
returned to the seat 123 to tell it to wait, and the seat's ID is kept on the 
Seatlnterface: :PendingSeats queue. Once a seat has a Session 507 assigned to it, it 
can communicate freely with the Service 477 v ia the NAU 465 until it closes or releases 
the Session. 

15 The following table illustrates a Sample Session Communication Flow. 
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Seat Seat NAU Sales Service 

Session Control - 
OPEN> 


<Session Status - Pending 


Session Control - 
SDU Pending> 


< Session Status - Opened 


Transaction 
Command - 
Order> 


Transaction Command - 
Order> 


<Transaction Status - 
Ordered 


transaction Status - Paid 


Transaction 
Command - 
Order> 


Transaction Command - 
Order> 


transaction Status - 
Ordered 


transaction Status - Paid 


Session Control - 
Close> 


<Session Status - Closed 

Each Seatlnterface VLRU 651 has a Session class, called the_Session to support this 
which uses an EventStateTable that keeps track of the action to perform for any given 
Event and/or State. Each action is maintained as a separate function whose name 
begins "Ac” (e.g., AcTerminateSelfQ ). These Action functions are all static BOOL 
5 functions that need the current Session and Event pointers passed to them to operate. 
| They are called by the function CrankQ 651a after it looks them up in the 
EventStateTable. 
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The following state table, called "Action" in the software, shows the relationship 
between the States, Events, Actions and changed or new states, sorted by From-State. 
Using this table, one can see how a Seat's Session moves from one state to another, 
which events can trigger the change and what actions are performed to cause the 
5 change. In the software, the events are prefixed with "Ev" (such as "EvSelfBackOut"), 
actions with "Ac" (such as "AcBackOut") and states with "St" (such as "StBackOut"). 
These prefixes are omitted from the table below for easier reading. 


From-State 

(St...) 

Event Trigger 
(Ev...) 

Action Function 
(Ac...) 

To-State (St...) 

BackOut 

SelfBackOut 

BackOut 

BackOut 

BackOut 

ServiceBackedOut 

BackOut 

BackOut 

BackOut 

SelfBackOutDone 

BackOutDone 

Opened 

CancelPending 

ServiceCanceled 

ServiceGeneralAction 

Opened 

CancelPending 

SelfTimeOut 

GeneralTimeOut 

Terminating 

Closed 

SelfClosed 

SessionNormal- 

Terminate 

Terminated 

Closed 

SelfTimeOut 

GeneralTimeOut 

Terminating 

CompleteUpdate 

ByCommand 

SDUGetNext- 

Transaction 

SendTransaction- 

Update 

Complete- 

UpdatePending 

Complete- 

UpdatePending 

SDUGetNext- 

Transaction 

SendTransaction- 

Update 

CompleteUpdate- 

Pending 

Complete- 

UpdatePending 

SelfUpdateDone 

TransactionUpdate- 

Complete 

Opened 

Complete- 

UpdatePending 

SelfTimeOut 

GeneralTimeOut 

Terminating 

DeliveiyPending 

ServiceDelivered 

ServiceGeneralAction 

Opened 

Delivery Pending 

SelfTimeOut 

GeneralTimeOut 

Terminating 

End 

SelfTimeOut 

GeneralTimeOut 

Terminating 

Foo 

SDUPending 

SessionNotAvailable 

Paused 
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From-State 

(St...) 

Incremental- 

Update- 

ByCommand 

Incremental- 

UpdatePending 

Incremental- 

UpdatePending 

Incremental- 

UpdatePending 

Opened 

Opened 

Opened 

Opened 

Opened 

Opened 

Opened 

Opened 

Opened 

Opened 

Opened 

Opened 

Ordered 

Ordered 

Ordered 

OrderPending 


Event Trigger 
(Ev...) 

SDUGetNext- 

Transaction 


SDUGetNext- 

Transaction 


Action Function 
(Ac...) 

SendTransaction- 

Update 


SendTransaction- 

Update 


To-State (St...) 

Incremental- 

UpdatePending 

Incremental- 
U pdatePending 

Opened 

Terminating 

CancelPending 

Closed 

DeliveryPending 

Opened 

Opened 

Opened 

OrderPending 

RefundPending 

Terminating 

UpdateType- 

Pending 

UpdateType- 

Pending 

UpdateType- 

Pending 

Opened 

PaidPending 

Terminating 

Ordered 
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From- State 
(St...) 

Event Trigger 
(Ev...) 

Action Function 
(Ac...) 

To-State (St...) 

OrderPending 

SelfTimeOut 

GeneralTimeOut 

Terminating 

PaidPending 

ServiceNotPaid- 

ForReason 

ServiceNotPaid 

BackOut 

PaidPending 

ServicePaid 

ServicePaid 

Opened 

PaidPending 

SelfTimeOut 

GeneralTimeOut 

Terminating 

Paused 

SDUOpen 

Se ssionO penN o w 

Waiting 

Pending 

SelfSystem- 

NotAvailable 

SystemNotAvailable 

Closed 

Pending 

SelfSession- 

NotAvailable 

SessionNotAvailable 

Foo 

Pending 

SelfSession- 

Available 

SessionAvailable 

Opened 

Pending 

SDUOpen 

SessionTiyToOpen 

Pending 

Pending 

SelfTimeOut 

GeneralTimeOut 

Terminating 

RefundPending 

ServiceRefunded 

ServiceGeneralAction 

Opened 

RefundPending 

SelfTimeOut 

GeneralTimeOut 

Terminating 

Sessionlnit 

SDUClose 

SessionNormal- 

Terminate 

Closed 

Sessionlnit 

SDUOpen 

SessionTiyToOpen 

Pending 

Sessionlnit 

Terminate- 

Immediatly 

Sessionlnit 

Sessionlnit 

Sessionlnit 

SDUTerminate 

SessionAbnormal- 

Terminate 

Terminating 

Sessionlnit 

SelfTimeOut 

GeneralTimeOut 

Terminating 

Sessionlnit 

SelfStatisticsNotify 

SendUpdate- 

NotifyToSDU 

UpdateNotify- 

AckPending 

Sessionlnit 

ServiceComplete- 

UpdateNotify 

SendUpdate- 

NotifyToSDU 

UpdateNotify- 

AckPending 
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From-State 

(St...) 

Event Trigger 
(Ev...) 

Action Function 
(Ac...) 

To-State (St...) 

Sessionlnit 

Servicelnc- 

UpdateNotify 

SendUpdate- 

NotifyToSDU 

UpdateNotify- 

AckPending 

Sessionlnit 

ServicelncUpdate- 

NotifyWithRevoke 

SendUpdate- 

NotifyToSDU 

UpdateNotify- 

WithRevoke- 

AckPending 

Start 

Start 

Sessionlnit 

Sessionlnit 

Start 

SelfTimeOut 

GeneralTimeOut 

Terminating 

Terminated 

SelfReinitialize 

Sessionlnit 

Sessionlnit 

Terminated 

SelfTimeOut 

GeneralTimeOut 

Terminating 

Terminating 

SelfTerminated 

Terminated 

Terminated 

Terminating 

SelfTimeOut 

GeneralTimeOut 

Terminating 

TVOffAck- 

Pending 

SelfTimeOut 

UpdateNotifyTimeOut 

DontChangeState 

TVOffAck- 

Pending 

SDUTVOffAck 

ServiceUpdate- 

NotifyComplete 

Sessionlnit 

TVOffAck- 

Pending 

SelfCancel- 

UpdateNotify 

DoNothing 

Sessionlnit 

UpdateNotify- 

AckPending 

SelfTimeOut 

UpdateNotifyTimeOut 

DontChangeState 

UpdateNotify- 

AckPending 

SDUUpdateNotify- 

AckFromSDU 

ServiceUpdate- 

NotifyComplete 

Sessionlnit 

UpdateNotify- 

AckPending 

SDUUpdateNotify- 

AckFromSI 

ServiceUpdate- 

NotifyComplete 

Sessionlnit 

UpdateNotify- 

AckPending 

SelfCancel- 

UpdateNotify 

DoNothing 

Sessionlnit 

UpdateNotify- 

WithRevoke- 

AckPending 

SelfTimeOut 

UpdateNotifyTimeOut 

DontChangeState 

UpdateNotify- 

WithRevoke- 

AckPending 

SDUUpdateNotify- 

AckFromSI 

SendTVOff 

TVOffAckPending 
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From-State 

(St...) 

Event Trigger 
(Ev...) 

Action Function 
(Ac...) 

To-State (St...) 

Update- 

TypePending 

SelfCompleteType 

SendU pdateType 

CompleteUpdate- 

ByCommand 

UpdateType- 

Pending 

SelflncrementalType 

SendUpdateType 

Incremental- 

UpdateBy- 

Command 

Waiting 

SelfSessionAvailable 

SessionAvailable 

Opened 

Waiting 

SelfSession- 

NotAvailable 

SessionN otAvailable 

Waiting 


All possible From-State/ Event Trigger combinations are not represented in the Action 
table. Many do-nothing or illogical combinations need to default. For that reason, the 
Action table is used to fill in a larger, more comprehensive table called the 
EventStateTable. This two-dimensioned table uses the values of From-State and Event 
5 Trigger as indexes, and defaults the illogical values to either do nothing or to terminate. 

A typical session flow (with no errors) to place an order would start and end in the 
Sessionlnit state as shown below: 
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From-State 

(St...) 

Event Trigger 
(Ev...) 

Action Function (Ac...) 

To-State (St...) 

Start 

Start 

Sessionlnit 

Sessionlnit 

Sessionlnit 

SDUOpen 

SessionTryToOpen 

Pending 

Pending 

SelfSessionAvail 

able 

SessionAvailable 

Opened 

Opened 

SDUOrder 

SDUOrder 

OrderPending 

OrderPending 

ServiceOrdered 

ServiceOrdered 

Ordered 

Ordered 

SDUPayment 

SDUPayment 

PaidPending 

PaidPending 

ServicePaid 

ServicePaid 

Opened 

Opened 

SDUClose 

SessionClose 

Closed 

Closed 

SelfClosed 

SessionNormalTerminate 

Terminated 

Terminating 

SelfTerminated 

Terminated 

Terminated 

Terminated 

SelfReinitialize 

Sessionlnit 

Sessionlnit 


5 


Each Session 507 has a SessionQueue queue pair that is used to store the Events to 
perform for this Session's State Machine. The SessionQueue's Right queue 651c stores 
incoming message/ event pointers for Session: :Crank() 651a to process, while its Left 
queue 651b stores outgoing event/message pointers for SeatInterface::StartItUp() 518 to 
forward to either the message processor 40 4452 or the transaction dispatcher 424 4-73 
or timeouts as appropriate. 


Broadcast VLRU 

The SeatBroadcast VLRU 652 is a child of the Seatlnterface class so that it can help 
10 monitor the seat communication traffic for the other Seatlnterface objects. It is 

responsible for sending messages to more than one seat or more than one Seatlnterface 
| VLRU 652 . Only one message is actually sent in a broadcast to the seats with the 
destination set to "AllSeats". It uses the CalledTimeOut utilities to create a TimeOut 
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Thread called SeatBroadcastTimeoutQ to force periodic, unsolicited broadcasts. It also 
launches the PendingSessionMonitorQ 652a and WheelStatusMonitorQ threads 652b . 

It's StartltUpQ 518 function loops forever, retaining possession of one of the SessionQ 
507 threads. It continuously monitors messages and processes the following events or 
messages: 

Action 

Tells all SDU-SI boards the current status of the HSDL 
Queue. Retriggers the 
HSDLInterface::ProcessDownLoadQ() event. 

Tells the MP what the Movie Run Times are 

Triggers every tenth of a second using the 
timedCallback::queue() function. When received, this 
broadcasts a "Session Complete" message to all seats if 
a Service Session has just completed, so they can retry 
communications, if needed. 

\ 

Tells all VLRUs to "SubProcessReinit". 

Uses ProcessSeatTransferQ to parse and forward this 
message to the two Seatlnterface VLRUs that are 
involved in the transfer. 

Tells all VLRUs to "SubProcessReinit". 

Stops the Timeout thread and ends the program. . 

Tells all VLRUs to Start Statistics Capture, now that the 
aircraft has landed (ending flight). 

The PendingSessionMonitorQ 652a has nothing to do with Seat Broadcasting: It is a 
supplement to the normal Seatlnterface processing. This monitor continuously waits 
for a Seat 123 to be put onto the static Seatlnterface: :PendingSeats queue (by any of 
the other Seatlnterface:: StartltUpQ threads), and then waits until one of the Seat 
Sessions is available for processing. Then it puts this Seat ID onto the AuxFifo queue 
to be taken by the next available SessionQ thread 507 . 

The WheelStatusMonitorQ 652b is a High Priority thread that waits for a signal from the 
PESC-A VLRU in the Backbone NAU, which pulses the Weight On Wheels or the Weight 


Message or Event 

CPMS Message 

MovieTimes Message 
NAU.TIMEOUT Event 

ProcessReinit Message 
SeatTransfer Message 

SubProcessStart Message 
SubProcessStop Message 
Weight_On_Wheels Event 
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Off Wheels events when their status changes. This monitor forwards this event 
information to the StartltUpQ 518 to process when it next loops. 

HSDL VLRU 

The HSDLInterface ebieet VLRU 650 is a standard NAU child dedicated to servicing all 
5 download requests for games or application programs by the seats. Its constructor 
connects to the driver, "HSDL1" to transmit -data to the seats via the Digitized Video 
Multiplexer system. The constructor also prefills a CRC Table used for deriving the 
CRC values during downloads. It creates a Mutex to control access to the HSDL 
directory to ensure that the routines in COPYDNL.CPP and SDU_BLDR.CPP don't 
10 interfere with the download process by modifying the files in the download directory at 
the wrong time. 


The StartltUpQ 518 routine launches the following threads: 

Thread Function 

ProcessFileChangesQ Reacts to changes in the NT Registry as well as changes 

in the Download Files Directory. It then calls 
ProcessEntireDirectoryQ to read the directory that 
contains the files that can be downloaded, creating a 
DownLoadFilelnfo object for each, and placing all 
download files in the ConvertQ for RefreshThreadQ to 
handle. This thread places all programs and database 
files ahead of games in the ConvertQ so that the Seats 
can be ready for use as soon as possible. 

RefreshThreadQ Looks for files in the ConvertQ queue to prepare for 

later downloading. Calls DownLoadFilelnfo: :RefreshQ to 
block the data and add checksums and CRCs for Seat 
verification. It also saves the identity of the requesting 
seat for communication during the actual download. 
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Thread Function 

ProcessDownLoadsQ This thread is launched at a low priority, so that the 

others can prepare all the files beforehand. It calls 
ProcessDownloadQO to use 

SeatInterface::GetDowriLoadInstruction() to handle this 
file properly. Calls DownLoadFileInfo::Download() for 
each file in the DownLoadQ to actually send them to 
the output driver. During the download, it redirects 
message handling away from the seat's SEB and toward 
its SDU I/F board because the seat display unit 
13 3122a can't receive messages without its application 
running, which is true whenever it is receiving a 
download. 

Then StartltUpQ calls ProcessIOQueuesf) to continuously sample the message processor 
and transaction dispatcher input queues. It processes the following message processor 
messages: 


IFB Message 

HighSpeedDownload 

SubProcessStart 
SubProcessStop 

The VCP NAU controls communications with the video players and other video sources. 
5 It maintains one VLRU for each video source, and constantly polls the players for their 
status. The VCP Network Addressable Unit program 463462 function and data paths 
are shown in Figure 3619. The structure of the VCP NAU 46 3462 is substantially the 
same as the Network Addressable Units function and data paths discussed with 
reference to Figure 3313. 

10 VCP.EXE contains the VCP NAU program. This program includes the following primary 
components: 


Action 

Puts the download request onto the DownLoadQ. It 
moves a request to the top of the queue if the request is 
for a program (high priority). 

Simply recognizes this command, no further 
processing. 

Flushes its MP and TD Input queues and tells the 
DestructFifo queue (one of the few VLRUs to use this) 
that it can be shut down. 


VNUMAIN.CPP 


The MainQ Program 
The NAU Dispatcher 
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VCPNTRFC. CPP The VCP VLRU Interface Class 

VCPSTSVL.CPP The VCP Status VLRU Class 


Main Program 

Main() issues a call to GetLruInfoQ to read the database 493 for all the VCP names (e.g., 
"VCP01"). It then launches a VCPDispatch object to open up communications between 
the message processor 404 452 and the transaction dispatcher 404 473 . It calls 
VCPDispatch: :startRUp() to initialize the VLRUs, one for each video cassette player 227 
plus one for periodic statusing of all video cassette players 227. It also launches the 
Session/) threads 507 . 

Main/) then calls ConsoleCmdQ to process all console characters that may be in the 
input buffer. If "S" is encountered, a STOP command is issued to VCP01. If "P" is 
encountered, a PLAY command is issued to VCP01. This is for testing purposes only. 

Finally, Main () sleeps forever until interrupted. It calls shutltDown () to close all the 
VLRUs down and exit gracefully. 

VCP Int e rfac e VLRU 

A VCP VLRU is created for each video cassette player 227 in the database 493 using 
the VCPInterface Class. This class is derived from the Generic NAU Classy however, 
due to the communications protocol employed by the players, many of the generic 
functions are overcast or not used at all. 

The VCPInterface/) constructor creates two unique controllers: Static hlOSemaphore 
and bHasSemaphore. These are used to enforce single-threaded communications 
between a video cassette player 227 -and the transaction dispatcher 42- 4473 . Using 
these controllers, only one VLRU can be processing communications at a time. 
hlOSemaphore is a handle that acts as 'dibs': When this handle is owned by a thread, 
that thread can process communications. bHasSemaphore is a local flag that tells the 
thread whether it currently is the owner of the semaphore. 

VCPInterface: :StartItUp() is called immediately for each Session () to process a 'dummy' 
message from the message processor 40 4452 for each of the video cassette players 


98-PS-039 



-319- 


227 . This 'dummy' message was invoked at their creation to glue each video cassette 
player 227 -to its own Session. 

This function then loops forever to continuously process messages. (This is contrary to 
th e g e n e ric VLRU proc ess ing logic, that r e l e a ses th e-sess ion - a s s oon a s a m e ssag e has 
b ee n proc e ss e d, but s inc e w e hav e e nough s e ssions availabl e , w e can p e rman e ntly 
assign th e m.) T he basic loop does the following: 

If this session does not have dibs, it waits for input from the transaction dispatcher 
424 473 and waits for the hlOSemaphore. Then it flushes all possible input from the 
message processor 404 452 , reads the transaction dispatcher message and transmits it 
to the message processor 404 452 . It retains ownership of the I/O handle, and loops 
again. 

If this session already has dibs (from the previous paragraph), it waits for input from 
the message processor 404 . Once received, it processes it and sends an 
acknowledgement back to the video cassette player 227 -via the message processor 
404 452 . It then releases dibs for use by the other VLRUs. 

VCP Status VLRU 

A single VLRU of class VCPSts_VLRU is created to periodically poll the players for their 
status. Two lists of information are used to organize this: MessageMap, that contains a 
list of each video cassette player 227 -and its network address; PendingStatus, that 
contains a list of video cassette players 227 that have just completed a communications 
event. MessageMap is maintained via AddVLRUQ as each VCP VLRU is created by the 
dispatcher. PendingStatus is maintained by XmitResponseQ each time the VCP VLRU 
completes a communications event. 

VCPSts_VLRU contains a timeout function that is invoked approximately 10 times per 
second. The StartttUpQ 518 function is immediately invoked and tied permanently to a 
Sessionf) 507 thread. It then loops forever waiting for both a timeout to occur and the 
hlOSemaphore to be available. Once both events have occurred, it examines the 
contents of the PendingStatus string list and prompts the topmost video cassette player 
227 -on this list for its status. If none are on this list, it prompts the next video 
cassette player 227 -in the MessageMap list. This is performed via SendStatus(). These 
status responses are formatted and forwarded to the Video Control Service via the 
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| transaction dispatcher 42 4473 . The I/O semaphore is released and the process cycle 
repeats. 

T es t Port NAU 

The Test Port NAU program 461 function and data paths is shown in Figure 3720. The 
5 Test Port NAU 461 controls communications to the serial test port for BIT/BITE and 
MAINT system access. The structure of the Test Port NAU 461 is substantially the 
same as the Network Addressable Units function and data paths discussed with 
| reference to Figure 2313. However, the Test Port NAU 461 includes NAU VLRU state 
machine objects 510d comprising a LoopbackThread() 660, a EthemetThread() 661, a 
10 VCPStatusThread() 662, and a Loopback Timout() 663 that are initiated by StartltUpQ 
518. 

The Test Port NAU program 461 has two exclusive behaviors: BIT test mode and BITE 
test mode. The Test Port NAU program 461 starts out in BIT mode, and upon receipt of 
a GO_BITE command (presumably from the PESC-A 224a), it attempts to switch to 
15 BITE mode. BITE test mode is only available while the aircraft 111 is on the ground (as 
indicated by weight-on-wheels). 

A BITE test is a three-pass ’loopback* in which data is sent to one of the I/O devices 
(the primary access terminal 225 to test the Ethernet network 228, a PESC-A 224a to 
test the ARCNET 216, and VCP Status Service to test video cassette players 227) and 
20 an answer is expected back. 

BIT tests are continuously occurring loopback' tests, however 3 consecutive failed 
communications are needed before a fault is recorded for any I/O device. A BIT test 
failure is only reported once per device per flight. 

All BIT/ BITE information is forwarded to a 'depository' or line replaceable unit that 
25 stores the information. In addition, BITE tests axe initiated by an outside source or 

BITE Host. The default value for both of these is the primary PESC-A 224a, however, a 
SET_DEPOSITORY command executes SetBITEDepository() to alter these values. 

TESTPORT.EXE contains the Test Port NAU program 461. The Test Port NAU program 
461 includes the following primary components: 
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TESTPORT. CPP 
TSTPRTDS.CPP 
TSTPRTVL. CPP 


The MainQ Program 
The NAU Dispatcher 
The VLRU Class 


5 


10 


The Main Program is a standard NAU starter. Main() registers the program with the 
System Monitor 412 using the SysMonInterfaceClass::Register() routine. Main() 
launches a TestPortDispatch object to open communication between the message 
processor 40 4452 and the transaction dispatcher 421 473 and calls 
TestPortDispatch: .startltUpQ to initialize the VLRU. Mamf/Launches two Sessionf) threads 
507. although only one is actually busy. MainQ sends a SubProcessStart command to 
the TestPort VLRU which causes the first SessionQ thread to connect to the VLRU 
permanently. Finally, MainQ sleeps forever until interrupted. MainQ does not call 
shutltDownQ to close all the VLRUs down and exit gracefully, it deletes the VLRU and 
dies. 


A single Test Port VLRU is created using the TestPortVLRU Class. This class is derived 
from the Generic NAU Class, however it overcast the communications routines to 
support the TestPort_Message Class data routines. This constructor reads the database 
to develop a table of all Test Port LRUs, PESC LRUs, Process LRUs, ADB LRUs and 
15 ALAC LRUs. This table of LRU addresses is passed to the TestPort VLRU for reference 
in GetSourceAddressQ and SetBITEDepositoryQ. 

TestPortVlru::StartItUpQ is called immediately for the first SessionQ to process a 'dummy' 

| message from message processor 404 452 . This 'dummy' message wasis invoked at 
their creation to glue the VLRU to a Session (a SubProcessStart message). 

20 The VLRU then creates a set of 6 events used to communicate to 3 new threads: 


Thread Name 

Event 1 

Event 2 

ARCNET LoopbackThread 

Message 

Abort 

EthemetThread 

Message 

Abort 

VCPThread 

Message 

Abort 


This function loops forever to continuously process messages to-and-from the message 
processor 404 452 . As a message is received, it is tested for validity, and then passed 
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to the appropriate thread via a Message Event. Typically, the Message Events are used 
to determine what to do next, however to end BITE mode testing, the Abort Event is 
triggered for each thread to stop BITE testing, making BIT testing possible again. 


5 I StartltUpQ 518 uses the TimedCallback Utility Class to periodically launch 

LoopbackTimeoutQ which is responsible for issuing a command to the ARCNET network 
216, the primary access terminal 225 and the VCP Service to initiate a 'loopback' test, 

| in that it causes these devices to respond. Failure to respond within a specified 
timeframe causes the associated thread to log that device as FAILED. The initiation is 
10 accomplished by calling PerformLoopbackQ . It uses its own versions of NAUPutMPQ and 
NAUPutTDQ to communicate because it needs to use the TestPort_Message class instead 
of IFE_Message class routines to process the data. 
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10 


15 


20 


25 


30 



b e k>W r 


Sp ee d Download driv e r Figure 10 p rovides the ability to convert this information into a 
Synchronou s D a ta Link Control svnchronous data link control (SDLC) data stream. 

This data stream is forwarded to the video modulator (VMOD) 312 212b to broadcast to 
all seats 123 via the RF distribution system. Any seat 123 that requires the download 
can then tune to the download channel and retrieve the information. HSDL.SYS is the 
high speed down load driver, written in C as a standard WINDOWS NT driver. 
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HSDL.SYS is the High Speed DownLoad driver, written in C as a standard 
Window s WINDOWS NT driver, and includes the following files: 


CONFIG. C 
DISPATCH. C 
DMA.C 
HARDWARE. C 

HSDLLIB.C 

INIT.C 

ISR.C 


Code for the initialization phase of the HSDL device driver. 
Code for the function dispatcher. 

Code for input and output which is non-hardware specific. 

Code for communicating with the Zilog 85230 processor on 
the HSDL card. 

Common code for HSDL Kernel mode device drivers. 

Code for an initialization phase of the HSDL device driver. 

Code for an Interrupt Service Routine for the HSDLBlaster 
device driver. 


REGISTRY. C Common code for Sound Kernel mode device drivers for 
accessing the registry. 

The HSDL device is a Zilog 85230 Enhanced Serial Communications Controller (ESCC), 
which is an industry-standard serial controller. HSDL is a Synchronous Data Link 
5 Control (SDLC) data stream running at 409.6 Kbps with 514-byte frames using FMO 
(biphase space) data encoding. To move the data as quickly as possible, DMA transfers 
are employed. 


The driver is registered as "\\HSDL1" and the following NT driver commands are 
supported: CreateFileQ, WriteFile(), DeuiceloControlQ and CloseFileQ. The calling program 
10 writes to the device in 514-byte blocks. Currently, only CreateFileQ and WriteFileQ are 
used in the system 100. 

S e rvic e s 

The application functions are divided into Services 477 that are responsible for carrying 
out the requests that come from the various devices (Seats 123 , PAT GUI 426 , etc.). 

15 | Requests come in two forms: IFE_Messages from the transaction dispatcher 4 21. 473 
and CAPI calls from the GUI 426 . Service functions are the primary functions that 
interact with the database 493 during runtime. Each Service is connected to the 
| transaction dispatcher 42 4473 via its own Named Pipes, and as needed, it connects to 
the SQL Server 492 for database access. 
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SERVICE. EXE is organized into 4 basic components: Main, CAPI Calls 476 , Cabin 
Services 478 - 482 , 487-494490 and Sales Services 483 - 486 . The Cabin Services 478 - 
482 , 487-4 91 490 and Sales Services 483-486 are sets of Service classes whose objects 
each connect to the transaction dispatcher 424 -473 via named pipes. They also each 
have a thread and subroutines to process all IFE messages received, and they all have 
sets of functions that are used by CAPI.CPP routines of the same name. 

SERVICE.EXE is comprised of the following source files: 


SRVCPRCS.CPP 

CAPI_S.C 

CAPI.CPP 

CBNSRVCC.CPP 
CRDTCRDP. CPP 
DTYFRSRV. CPP 
GMSRVCCL.CPP 
IFCNTRLS.CPP 
MVCYCLCL.CPP 
MVSRVCCL.CPP 
OFFLOADR. CPP 
PCKGSRVC.CPP 
PLYRCNFG. CPP 
SET. CPP 
SLSSRVCE.CPP 
VCPMSSGE.CPP 


The Main Program and Service Class 

The RPC Server Functions (See CAPI_C for its client 
companion functions) 

The actual CAPI Application Functions, called by 
CAPI_S.C, APIINT.CPP, and the Services. 

The CabinService Base Class 

The CreditCardProcessor Class 

The DutyFreeService Class 

The GamesService Class 

The IFEControlService Class 

The MovieCycle Class 

The MovieService Class 

Database Offloader Functions 

The PackageService Class 

The PlayerConfiguration Class 

The Set Class (to support the _Set table) 

The SalesService Base Class 

The VCP_Message Class (see MESSAGES. LIB for 
details) 


VDNNNCMN.CPP The VideoAnnouncement Class 
VDSRVCCL.CPP The VideoService Class 
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| The Services NAU program 477 function and data paths are shown in Figure 3821. 
Located in SRVCPRCS.CPP file, the mainQ program is responsible for launching each of 
the services. Once launched, they are each connected to the named pipes that 
communicate with the transaction dispatcher 43 4473 . 

5 The services include CAPI.CPP calls 701 which access CAPI_S.C. calls 702 that access 
CAPI_C.C programs 427 . The services include an IFEControlService Class 703 , 
MovieCycle, VideoService and VideoAnnouncement Classes 704 , and SalesService, 
MovieService and GameService Classes 705 . The Services NAU program 477 includes a 
ServiceProcessor 706 that employs a GetContextHandle() 722 a 
10 ContextHandleSessionQueue 723 , and a PutcontextHandle() 724 . 

The IFEControlService Class 703 employs a CabinService::Get Message() thread 711 
and a CabinService::Put Message() thread 712 that are coupled to the transaction 
dispatcher 434 473 by way of name pines 474 . The CabinService::Get Message() thread 
711 is routed to an InQueue 713 to a ProcessRequest() 715 which accesses IFE 
15 Message Support Functions 718 . The ProcessRequest() 715 is coupled by way of an 

OutQueue 743714 to a CabinService::Put Message() thread 712 which is coupled to the 
transaction dispatcher 43 4473 by way of the name pipe 474 . A 
TimeSynchronizationThread() 716 is also routed through the OutQueue 743714 and 
CabinService::Put Message() thread 712 . CAPI Support functions 717 are routed to the 
20 CAPI.CPP calls 701 and to the SQL server 492 . The IFE Message Support Functions 
718 access the SQL server 492 . 


25 


30 


The MovieCycle, VideoService and VideoAnnouncement Classes 704 employs a 
CabinService::Get Message() thread 711 and a CabinService::Put Message() thread 712 
that are coupled to the transaction dispatcher 43 4473 by way of name pipes 474 . The 
CabinService::Get Message!) thread 711 is routed to an InQueue 713 to a 
ProcessRequest() 715 which accesses IFE Message Support Functions 718 . The 
ProcessRequest() 715 is coupled by way of an OutQueue 743714 to a CabinService::Put 
Message!) thread 712 which is coupled to the transaction dispatcher 434 473 by way of 
the name pipe. A - Tim e SynchronizationThr e ad() 716 is also rout e d through th e 
OutQu e u e 713 and CabinS e rvie e i -f Fu t- M e s s ag e !) thr e ad 712 . - CAPI Support functions 
717 are routed to the CAPI.CPP calls 701 and to the SQL server 492 . The IFE 
Message Support Functions 718 access the SQL server 492 . 
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The SalesService, MovieService and GameService Classes 705 employs GetMessageQ 
719 and PutMessage() threads 719 , 720 that interface to the transaction dispatcher 
424473 by way of name pipes 474 , The Get-Message() thread 719 is routed by way of 
an InQueue 713 to a ProcessRequest() 715 which accesses IFE Message Support 
Functions 718 . ProcessRequest() 715 are routed by way of an OutQueue 743714 to 
the Put Message}) thread 742720 which is coupled to the transaction dispatcher 
4 21 473 by way of the name pipe 474 . CAPI Support functions 717 are routed to the 
CAPI.CPP calls 701 and to the SQL server 492 . The IFE Message Support Functions 
718 access the SQL server 492 . 


10 The mainQ program establishes a logon to the SQL Server 492 for database access 
using the standard SQL library commands in NTWDBLIB.LIB library. The mainQ 
program establishes 10 SQL Sessions, for example, with Context Handles to be used by 
the Services 477 to talk to the database 493 . The mainQ program establishes multiple 
handles to the database 493 for all the services and CAPI functions to use, then starts 
15 Pipe Threads and Process Threads for each service to run independently. 


The mainQ program establishes itself as an RPC Server to communicate with the PAT 
GUI 426 and any other RPC Clients with the NT RPC utilities. Any program that has 
CAPI_C.C linked into it is an RPC Client in the system 100 . The mainf) program 
registers itself with the system monitor 442 454 for subsequent Shutdown support with 
20 SystemMonitor::RegisterQ . The mainQ program issues a call to ServiceProcessor:: 

StartActivityMailSlotThreadQ to hook up to the primary access terminal NAU’s GUI 
Monitor process, periodically sending it a message to let it know that Sendee is alive 
| and well. Finally, the mainf) program waits forever listening to the RPC Server that it 
set up (via RpcServerListenQ ) until System Monitor's ShutdownQ kills the process. 


25 


S e rvic e Proc es sor Cla ss 


| The ServiceProcessor class is used by mainQ and the Services 477 to control the access 
to the database 493 using the finite number of Context Handles available. This 
| program has more Service SQL functions than we-4e-Context Handles. It is conceivable 
that as many as 25 SQL requests may be present at one time (10 games, 10 movies, 1 
30 CAPI, 1 IFE Control, 1 Movie Cycle, 1 Video Service and 1 Video Announcement). As a 
result, this code provides for optimum processing efficiency by queueing up the 
available Context Handles and issuing them on a first-come first served basis. 
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ServiceProcessor Public Functions 

CONTEXTHANDLESTRUCT * 
GetContextHandle() 

int 

GetContextHandleCountQ 

HANDLE 

GetContextHandleSemaphoreQ 

DWORD 

GetLastError( 

PCONTEXT_HANDLE_TYPE phContext) 
void 

PutContextDB( 

int dContextLocation, 

DBPROCESS*pDBProc) 

void 

PutContextHandle( 

CONTEXTHANDLESTRUCT* 

pContextHandle) 

void 

PutContextHandle( 
int dContextLocation) 

void 

SetLastError( 

PCONTEXT_HANDLE_TYPE phContext, 
DWORD dwErrorCode) 


bool 

StartActiuityMailSlotThreadQ 


Th e S e rvic e Cla s s 


Purpose 

Returns the handle to the next available 
context structure for access to the 
database. 

Returns the number of available Context 
Handles. 

Returns the semaphore for the context 
handle Queue. 

Retrieves the error code associated with 
the specified context handle (phContext) 
that was most recently set by the 
SetLastErrorQ member function. 

Adds the DPROCESS handle to the 
context handle structure. 


Replaces the context structure into the 
context structure queue. Service Classes 
use this one. 


Adds the context structure to the context 
structure queue. The main() program 
uses this one to initialize the queue. 

Associates the error code in dwErrorCord 
with the context handle pointer 
(phContext) storing them in the 
LastErrorMap structure. Values are 
retrieved from the structure via the 
GetLastErrorQ member. This makes the 
errors available to all RPC Clients outside 
the Services. 

Starts the Mail Slot Thread used for 
transmitting an Tm alive” signal to the 
PAT NAU GuiMonitor. 

Returns FALSE if fails to start the thread. 
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Based on the DBAccess class, the Service class is a template for all the Services 477 to 
follow for proper operation. As a result, all its functions are virtual, and are defined in 
its children classes. 


Service Class Virtual 
Functions 

virtual bool 
ConnectToTDQ 

virtual void 
GenerateReport( 
ReportType nReport) 

virtual void 
GetMessagef) 

virtual PolicyType 
GetPolicyQ 


virtual bool 
IsAvailableQ 


virtual void 
MakeAvcdlable( 
SERVICESTATE 
ServiceAction) 

virtual void 
ProcessRequestQ 


virtual void 
PutMessageQ 

The Cabin Services 


Purpose 


Abstract definition to interface supports Service-to-TD 
named pipe connections. 

Abstract definition to define the interface to launch a 
report. 

(All of them are stubs for now, and not called by anyone.) 
Abstract definition to receive data into the Service. 


Abstract definition to retrieve the access policy for the 
Service. 

(All of them are stubs for now, and not called by anyone.) 

Abstract definition that defines an interface to evaluate 
whether a Service is available and ready to process 
requests or commands. 

(All of them are stubs for now, and not called by anyone.) 

Abstract definition that defines an interface to make a 
Service available. 

(All of them are stubs for now, and not called by anyone.) 

Abstract definition for an interface that handles 
IFE_Messages for the Service. In addition to specific 
messages designed for each Service, all ProcessRequestQ 
functions should handle the SubProcessStart, 
SubProcessStop and SubProcessReinit messages to get 
themselves going and synchronized as needed by the rest 
of the system. 

Abstract definition to send data out of the Service to TD 
and beyond. 


Th e s e s e rvic e s 477 control all the functions of In-Flight Service except those in which 
individual passengers 117 are involved. Cabin Services 477 are divided into the 
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following Services: IFE Control Service 703 . Movie Cycle Service, Video Service and the 
Video Announcement Service 704 . In addition to its overcast versions of the Service 
class functions, CabinServiceClass includes: 


CabinServiceClass Public Purpose 

Functions 


TIME 

GetRemainingFlightTime 

(PCONTEXT_HANDLE_TYPE 

phContext) 

bool 

RegisterPipe 
(HANDLE hPipeHandle) 
bool 

SetStatus 

(STATUS_TYPE nStatusType, 
char *pszData) 

bool 

StartPipeThreads 


Retrieves the remaining flight time using the 
CalcRemainingFlightTime stored procedure. 


Registers this named pipe with the 
Transaction Dispatcher to make I/O 
possible. 


Transfers the data contained in pszData into 
the status message field identified by 
nStatusType. 


Called by mainQ to get a pair of named pipes 
to TD for this Service. 


(ServiceProcessor *pServiceProcessor) 


bool 

StartProcessThreads 
(ServiceProcessor *pServiceProcessor) 
static UINT 

GetMessageThreadlnterface 
(LPVOID IpParam) 
static UINT 

ProcessRequestlnterface 
(LPVOID IpParam) 
static UINT 

PutMessageThreadlnterface 
(LPVOID IpParam) 


Called by mainQ to get the child's 
ProcessRequestQ loop going by invoking 
ProcessRequestlnterfaceQ . 

Shared by all the CabinServiceClass 
children, this launches the child's 
GetMessageQ function to handle its input 
from TD. 

Shared by all the CabinServiceClass 
children, this launches the local 
ProcessRequestQ function that loops forever 
handling the messages that it receives. 

Shared by all the CabinServiceClass 
children, this launches the child's 
PutMessage() function to handle its output 
to TD. 
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CabinServiceClass Public Purpose 

Functions 

void Initiates a delay for the number of seconds 

Wait( specified by the input parameter dwSeconds. 

DWORD dwSeconds) 

IFE Control S e rvic e 


The IFEControlService 703 class is derived from the CabinService class and contains 
several additional sets of functions that are used sporadically throughout the flight 
including: 


5 


Function Set 

IFE State Changes 

Flight Duration 
Management 

Statistics 

Surveys 

Seat Transfers 

Database Backup 

CAPI support 


Tables Used 

Aircraft, Order_ 


Member, PassengerMap, PassengerStatistics, Set_ 
SurveyAnswer 

All Database Tables 


CAPI support 717 includes the following public functions accessed by CAPI.CPP 701 
calls (having the same name): 


IFEControlService Class Public Purpose 

Functions 

bool Formats an IFE Message as specified by 

CommandSeat nCommand and transmits the message to 

the seat specified by pszSeatName. 

(PCONTEXT_HANDLE_TYPE 
phContext, SEAT_COMMAND 
nCommand, 

PGENERIC _TEXT pszSeatName) 
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IFEControlService Class Public Purpose 

Functions 


bool 

SeatTransferlnit 

(PGENERIC_TEXT pszSeatl, 
PGENERIC.TEXT pszSeat2) 

void 

SendStatusMessage 

(PCONTEXT_HANDLE_TYPE 

phContext) 

bool 

SetIFEState 

(PCONTEXT_HANDLE_TYPE 

phContext, 

IFESTATE IFEStateValue) 


void 

SetRernaimngFlightDuration 

(PCONTEXT_HANDLE_TYPE 

phContext) 


Due to a CAPI call. Formats and sends an 
IFE_Message to the Seat NAU, which is 
where the actual transfer takes place. The 
data in the message reflects the two seats 
that are to be transferred. 

Formats and transmits an unsolicited 
Status Window Message to the GUI. 


Calls the local SetStccteQ to update the 
system state information. IFE State is a 
term that describes whether the IFE System 
is IDLE, STARTED, PAUSED, and more. 

This allows CAPI to alter these states to 
either free up services or disable them as 
appropriate for the current runtime state of 
the system. For example, when the system 
is IDLE or PAUSED, movies cannot be 
viewed which affects the Movie Cycle Service 
as well as the Movie Rental Service. 

Called to refresh the value contained in the 
tmRemainingFlightDuration which is 
defined statically in the CabinService class. 
This function is called periodically from the 
IF EControlSer vice: :Time SynchronizationThrea 
dj) thread to update the value as the flight 
progresses, and directly from the CAPI when 
a change to the flight duration occurs. 


IFE - M es sag e Support 

In addition to the CAPI support functions , thi s S e rvic e 717. the IFE Message Support 
718 also handles incoming IFE Messages using its overcast ProcessRequestQ thread 
715 . In addition to the standard messages, this class handles the following messages: 
Statistics, Survey, SeatFault, FlightlnfoRequest and DatabaseBackup. 

IFE Message Function Called Purpose Tables Affected 
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IFE Message 

DatabaseBackup 


Function Called 

ProcessDatabase 

Backupf) 


FlightlnfoRequest ProcessFlightlnfoQ 


SeatFault ProcessSeatFaultQ 


Statistics ProcessStatisticsQ 


Purpose 

Generates a 
backup of the 
entire CFS 
database to 
recover after a 
possible CFS 
hard disk failure. 

Gathers flight 
information from 
the CFS database 
and uses the 
information to 
populate an 
IFE_Message. 

The IFE_Message 
is then returned 
to the requesting 
program 

Updates the 
database, 
clearing or setting 
a fault indication 
for the seat or 
range of seats in 
the IFE message 

Stores statistical 
information from 
the seats to the 
database and 
prepares them for 
output to a text 
file. Statistics 
include 

information such 
as how many 
hours of which 
movie was 
viewed, which 
games were 
played and more. 


Tables Affected 

All database tables 


Aircraft 

FlightV 


PassengerMap 


Member 

Set_ 

PassengerMap 

PassengerStatistic 

s 
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IFE Message 

Function Called 

Purpose 

Tables Affected 

SubProcessStart 

InitServiceQ 

Establish IFE 
State and tell it to 
all affected 
programs via IFE 
Messages. Calls 
StartTimeSynchro 
nizationThreadQ 
to launch 
TimeSynchronizati 
onThreadQ 

Aircraft 

Survey 

ProcessSurveyQ 

Stores the 
answers given by 
passengers to 
survey questions 
available through 
the IFE system. 
These answers 
are stored in the 
database, as well 
as prepared for 
output to a text 
file 

Survey 

SurveyAnswer 

SurveyAnswerKey 

SurveyQuestion 


The T ime S vnchronizat ionThread 0 


This thread 716 in the IFEControlService class 703 is responsible for managing flight 
duration information, which changes all the time. It uses 

SetRemainingFlightDurationO to update values, and calls AutoEndRevenueO to send a 
Stop Revenue Unsolicited Message to the GUI 426 once there is no time for further 
revenue purchases. 


Play e rConfiguration Support Clas s 


The PlayerConfiguration class supports any Service that uses video players, such as the 
MovieCycle, VideoAnnouncement and Video Services 704 . The PlayerConfiguration 
class contains all pertinent information necessary to describe information specific to a 
Movie Cycle or Video Announcement. The PlayerConfiguration class also contains the 
methods needed to issue all appropriate messages to start a specific Movie Cycle or 
Video Announcement. 


PlayerConfiguration Class Public Purpose 
Functions 
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PlayerConflguration Class Public Purpose 
Functions 


PlayerConfiguration 

(Queue *pParentQueue, 
CString csName, 
CString csAddress, 
TIME tmlntermission, 
TIME tmStart) 

PlayerConfiguration 

(Queue *pParentQueue, 
CString csName, 
CString csAddress) 

void AddPlayer 

(CString csPlayerName, 
BYTE bySegment, 

BYTE byRepeat, 
DWORD dwMediald) 


bool ChangeCabinAudioLevel 

(BYTE byAudioLevel, 

BYTE byZone) 

void CommandCabinAudio 

(bool bAudioOn) 


void CommandCabinVideo 
(bool bVideoOn) 


Creates a PlayerConfiguration object of 
specified Name, Intermission Time and Start 
time. In addition, a reference to the parent 
object's queue is stored in order for this 
PlayerConfiguration object to communicate 
with the parent object. 


Same as above, except default values for 
Intermission Time and Start Time are 
assigned as Zero. 


Adds the specified player to this Player 
Configuration. If the program to be played 
is a Video Segment, then a segment number 
is provided, otherwise a value of zero is 
passed in the bySegment argument. If the 
repeat flag is set TRUE then the associated 
player is placed into it's REPEAT state. 

Updates internal data structures for this 
PlayerConfiguration object with the audio 
level specified in the byAudioLevel 
argument. 

Transmits the necessary messages to the 
Backbone NAU which command the PESC-V 
to make the necessary cabin audio 
connections for the zones associated with 
this Player Configuration object. If the input 
argument bAudioOn is TRUE, the 
connections are enabled, if bAudioOn is 
FALSE, the connections are disabled. 

Sends messages to the PESC-V to activate or 
de-activate the Overhead Monitors and 
override the in- seat video displays 
associated with this Player Configuration 
object. A value of TRUE for the input 
argument bVideoOn causes cabin video 
connections to be enabled, a value of FALSE 
for bVideoOn causes cabin video 
connections to be disabled. 
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PlayerConflguration Class Public Purpose 

Functions 

bool CommandPlayer Transmits the player command specified by 

nCommand to the player specified by 

(CString csPlayerName, csPlayerName. Any additional data needed 

PLAYERCOMMANDS nCommand, for the command must be passed in 
PGENERIC_TEXT pszExtra) pszExtra. 

bool CommandPlayers Issues the commands to start, stop or 

rewind the player. 

(PlayerCommands nPlayerCommand) 

bool CreateAssignmentMap 

(PCONTEXT_HANDLE_TYPE 
phContext) 

BYTE GetCabinAudioZoneMapO Returns the Cabin Audio Zone BitMap. 

BYTE GetCabinVideoZoneMap() Returns the Cabin Video Zone BitMap. 

CString GetConfigAddressQ Returns the Configuration Address. 

PLAYERSTATE GetConfigState() Returns the cumulative state of all players 

currently assigned in this 
PlayerConfiguration object. 

PLAYERSTATE GetConfigStateQ Returns the state of the Player's 

Configuration. 

Returns information pertinent to this 
PlayerConfiguration object. The information 
returned is: 

- Number of configurations started 

- Elapsed time current configuration has 
been playing 

- Remaining play time for current 
configuration 

- Number of minutes until the next 
Configuration starts. 

ConfigState GetCurrStateQ Returns the current configuration state. 

TIME GetCycleTimeQ Returns the sum of the Longest Program 

Time and the Intermission. 


void GetConfigStatus 

(ULONG *ulCurrentViewing, 
long *tmElapsed, 
long *tmRemaining, 
long *tmNextShow) 


Populates the static data structure 
AssignMap with a status record for each 
LRU of type VCP residing in the LRU table. 
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PlayerConfiguration Class Public Purpose 
Functions 

Computes a list of start times for all movie 
cycles contained in this PlayerConfiguration 
object. Cycle time values are store in 
dwCycleTimeList and the number of 
elements added to the array is returned to 
the calling function. 

long GetLongestProgramTime() Returns the Longest Program duration in 

minutes. 


int GetCycleTimes 

(TIME tmFlightRemaining, 
CDWordArray *dwCycleTimeList) 


CString GetLongestProgramVcpQ Returns the value of the Longest VCP 

Program name. 

Returns the Mediald associated with the 
Video Player specified in csPlayerName. A 
value of -1 is returned if an invalid player 
name is specified. 

CString GetNameQ Returns the configuration name. 


DWORD GetMediald 
(CString csPlayerName) 


int GetPlayerList 
(CStringArray &csList) 


Populates a CStringArray with a list of the 
VCP Player Names currently associated with 
this PlayerConfigurationObject. 


WORD GetPlayerStateCount Returns the number of players in this 

PlayerConfiguration object that are currently 
(PLAYERSTATE nPlayerState) in the state specified by nPlayerState. 


ConfigState GetPrevState() 


Returns the previous configuration state. 


BYTE GetSeatVideoZoneMapO Returns the Seat Video Zone BitMap. 

TIME GetStartTimeQ Returns the Start Time. 


bool GetTimeoutFlagO 


Returns the value of the Timeout Flag. 


PLAYERSTATE GetVCPState Returns the state currently stored in the 

assignment map for the player specified by 
(CString csVCPName) csVCPName. 

bool IsCabinAudioActiveQ Returns a value of TRUE to the calling 

function if cabin audio is being used by any 
of the currently active assignments. A value 
of FALSE is returned otherwise. 
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PlayerConfiguration Class Public Purpose 
Functions 


bool IsLastViewing 
(TIME tmFlightRemaining) 

bool IsRunningO 
bool IsTransitionActive () 

bool IsValidVCP 
(CString csVCPName) 

void PurgeQ 

void RecoverCycle 
(IFE_Message *msgRecoveiy!nfo) 


bool ReplacePlayer\ 
CString &cs01d, 
CString &csNew) 


void ResetTransitionActive() 

void SetAudioDistributionlnfo 

(BYTE byAudioMap, 

BYTE byMapType, 

CByte Array *pby Volume) 

bool SetConfigState 

(ConflgState nState) 


Determines whether or not the cycle being 
played is the final cycle based on the 
remaining time in the flight. It returns a 
value of TRUE if the last cycle has started 
and returns a value of FALSE otherwise. 

Returns TRUE if the current state is IDLE. 

Returns TRUE if Transition is marked as 
active. 

Returns a value of TRUE to the calling 
function if the player name specified by the 
csVCPName argument is found in the 
Assignment map. Otherwise a value of 
FALSE is returned. 

Removes references to all video player 
names and configuration data associated 
with this PlayerConfiguration Object. 

Extracts recovery information from the 
IFE_Message object referenced by 
msgRecoverylnfo, converts the data into 
Binary and uses the converted data to 
initialize timing information for this 
PlayerConfiguration object. 

Removes the player identified by csOld from 
this PlayerConfiguration object and adds the 
player identified by csNew to this 
PlayerConfiguration object. 

Sets Transition to InActive. 

Stores the Audio distribution information for 
this Player Configuration. 


Sets the state of this PlayerConfiguration 
object to the value specified by nState. 
Performs all initialization necessary to make 
the transition into the new state. Returns 
TRUE if the state was successfully entered, 
returns FALSE otherwise. 


98-PS-039 



-340- 


PlayerConfiguration Class Public Purpose 
Functions 


void Setlntermission 

(TIME tmlntermission) 

void SetLongestProgram 

(int nPlayTime, 

CString csPlayerName) 

void SetStartTime 

(TIME tmStartTime) 

void SetTransitionActive() 


Sets the Intermission Duration for this 
Player Configuration. 


Identifies a VCP Name and Program 
Duration as the longest program in this 
PlayerConfiguration. 


Sets the player start time. 


Sets Transition to Active. 


int SetVCPAssignment 
(int nLockState) 


bool SetVCPState 

(CString csVCPName, 
PLAYERSTATE nVCPState, 
DWORD dwVCPTime) 

void SetVideoDistributionlnfo 

(BYTE byRFChannel, 

BYTE bySeatMap, 

BYTE byOHMap, 

BYTE byMapType) 

void UpdateConfigState 

(VCP_Message *pMessage) 


Updates the pConfig entry in the Player Map 
data structure associated the player 
identified by csVCPName. If the value of 
nLockState is LOCK the pointer to this 
PlayerConfiguration object is written. If the 
value of nLockState is AVAILABLE and the 
player is currently assigned to this player 
configuration object, the pConfig field is set 
to NULL. 

Returns the number of players which were 
successfully assigned. 

Updates the entry in the PlayerMap data 
structure associated the player identified by 
csVCPName with the value contained in the 
nVCPState argument. 


Stores the video distribution information for 
this Player Configuration. 


Updates the state of this 
PlayerConfiguration object based. The state 
may be changed based on the content of the 
input message or based on a timeout applied 
to the current state. 
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PlayerConfiguration Class Public Purpose 
Functions 


void UpdateConfigTimeout() 


void UpdateCycleStatus 

(TIME tmStatusUpdateRate, 
TIME tmRemainingCycleTime) 


Sets the state of the bConfigTimeoutFlag 
variable TRUE if the elapsed time for the 
current state has been exceeded. Otherwise, 
the bConfigTimeoutFlag variable is set False. 

Used periodically to transmit the Movie 
Cycle Times (based on RemainingCycleTime) 
message to the Seat NAU. Also periodically 
transmits a Recoveiylnfo message to the 
IFEControlService. 
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Movi e Cycl e S e rvic e 

Throughout the In-Flight operation, one or more movies continuously play, all starting 
together as a set, providing maximum viewing possibilities for the passengers 117 . 

This is known as Movie Cycling. The Movie Cycle Service controls the synchronization 
of these cycles. 

Derived from the CabinService class, -MovieCycleClass is responsible for keeping track 
of the remaining time of the flight, as well as the longest movie duration. It starts a 
cycle, stops a cycle, pauses a cycle, and recovers a cycle. The following database tables 
are used to support the MovieCycle Class: Member. MovieCycle, Set , VideoMedium, 
VideoPlaver, VideoSegment, and VideoUse. 

Tabl e s Us e d 

M e mb e r 

Movi e Cycl e 

Set 

Vid e oM e dium 

Vid e oPlay e r 

Vid e oS e gm e n t 

Vid e oUs e 

CAPI Support 

The following table shows those functions that are used by CAPI.CPP calls 701 : 
MovieCycle Class Public Functions Purpose 

bool Adds a player to a movie cycle. 

AddPlayerToMovieCycle 

(PCONTEXT_HANDLE_TYPE phContext, 

PGENERICJTEXT MovieCycleName, 

PGENERICJTEXT PlayerName) 
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MovieCycle Class Public Functions 

bool 

ChangeMovieCyclelntermissionTime 

(PCONTEXT_HANDLE_TYPE phContext, 
PGENERIC_TEXT MovieCycleName, 
TIME Intermission) 

bool 

ChangeMovieCycleStartTime 

(PCONTEXT_HANDLE_TYPE phContext, 
PGENERIC.TEXT MovieCycleName, 
TIME StartDelay) 

APIResult 

GetFirstMovieCycleTime 

(PCONTEXT_HANDLE_TYPE phContext, 
PGENERIC_TEXT pszMovieCycleName, 
TIME *tmMinUntilStart) 

bool 

GetMovieConfigurationState 

(PCONTEXT_HANDLE_TYPE phContext, 
PGENERIC_TEXT pszMovieCycleName) 

bool 

GetMovieCycleDuration 

(PCONTEXT_HANDLE_TYPE phContext, 
PGENERIC_TEXT pszMovieCycleName, 
TIME *tmDuration) 

APIResult 

GetNextMouieCycleTime 

(PCONTEXT_HANDLE_TYPE phContext, 
TIME *tmMinUntilStart) 


Purpose 

Modifies the movie cycle intermission 
time. 


Update the start delay time for the 
PlayerConfiguration object specified 
by MovieCycleName. Updates the 
start delay locally: The value is 
written to the database as part of the 
StartMovieCycle processing. 

Calculates the number of minutes 
until each of the remaining movie 
cycles starts. Returns the first start 
time in tmMinUntilStart. The return 
value is APIOK if there are 2 or more 
entries in the list and APIEndOfList if 
there is only 1 entiy in the list. 

Returns TRUE if the movie cycle 
specified by pszMovieCycleName is 
running. 


Returns the duration, in minutes, of 
the Movie Cycle specified by 
pszMovieCycleName. A return value 
of TRUE indicates that the specified 
movie cycle was found and the time 
is valid. 

After GetFirstMovieCycleTimeQ has 
been called to calculate movie cycle 
times and return the first one, this 
can be called iteratively to retrieve 
the remaining movie cycle start 
times. 

Returns APIEndOfList for the last 
entry in the list. 

Returns APIOK for all other entries. 
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MovieCycle Class Public Functions 

bool 

RemovePlayerF romMovieCycle 

(PCONTEXT_HANDLE_TYPE phContext, 
PGENERIC.TEXT MovieCycleName, 
PGENERIC_TEXT PlayerName) 

bool 

ReplaceMovieCyclePlayer 

(PCONTEXT_HANDLE_TYPE phContext, 
PGENERIC_TEXT pszMovieCycleName, 
PGENERIC_TEXT pszPlayeiToRemove, 
PGENERIC.TEXT pszPlayeiToAdd) 

bool 

SetMovieCycleUpdateRate 

(PCONTEXT_H AND LE_TYPE phContext, 
long lSeconds) 

bool 

StartMovieCycle 

(PCONTEXT_HANDLE_TYPE phContext, 
PGENERIC_TEXT MovieCycleName, 
TIME tmStartTime) 

bool 

StopMovieCycle 

(PCONTEXT_HANDLE_TYPE phContext, 
PGENERIC_TEXT MovieCycleName) 

void 

UpdateSystemState 

(PCONTEXT_HANDLE_TYPE phContext) 


IFE Message Support 


Purpose 

Removes the PlayerName player from 
the movie cycle MovieCycleName. 


Swaps players (usually because of a 
hardware failure, and movies must 
be moved to new devices). 


Sets the movie cycle update rate. 

The movie cycle update rate is the 
rate at which the system transmits 
movie cycle update information to 
the seats in seconds. 

Starts the specified MovieCycleName 
at the given tmStartTime. 


Stops the specified Movie Cycle. 


Notifies MovieCycleService that a 
change to the system state has 
occurred. The Service retrieves the 
system state from the database and 
updates the state of the active 
cycle(s) accordingly. 


This S e rvic e 718 handles incoming IFE Messages using its overcast ProcessRequestQ 
thread 715 . In addition to the standard IFE messages, this class handles the following 
messages: MovieTimes and MoineCycle . 
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IFE Message 

MovieCycle 

MovieTimes 

SubProcessStart 


Function Called Purpose 

StopMomeCycleQ or Starts or Stops the movie cycle as 

StartMovieCycleQ needed. 


UpdateMovieTimes() Updates the duration of the movies that 

are playing or scheduled to play. 


InitServiceQ Creates a PlayerConfiguration object, 

determines what the players are doing 
using UpdateSystemStateQ 
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Vid e o S e rvic e 

Flight Attendants often need the ability to view and listen to videos to verify quality and 
accuracy (for example, to determine if the expected movie is installed in the proper 
player 227). The Video Service functions support this capability. Derived from the 
CabinService class, the VideoServiceClass is responsible for connecting the GUI 426 to 
the individual players 227 for preview and overhead control. The following database 
tables are affected by the Video Service Class: VideoMedium. VideoPlaver. and 
VideoUse. 


Tabl e Nam e 

Vid e oM e dium 

Vid e oPlay e r 

Vid e oU se 


CAPI Support 


The following table shows those functions that are used by CAPI.CPP calls 701 : 


VideoServiceClass Public Purpose 

Function 

PLAYERSTATE 
CommandPlayer 

(PGENERIC_TEXT pszPlayerName, 

PLAYERCOMMANDS nCommand, 

PGENERIC.TEXT pszExtra) 

void Returns the state and channel # of the 

GetOverhead currently selected Overhead Video source. 


Uses PlayerConfiguration class functions to 
tell VCP pszPlayerName to perform 
nCommand (e.g., start, stop, play .... etc). 


(OVERHEADSTATETYPE 

*pOHState, 

long *pChannel) 
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VideoServiceClass Public Purpose 

Function 

PLAYERSTATE Uses CommandPlayerQ to prompt the VCP to 

GetPlayerState supply its current state. 

Returns this state to caller. 

(PGENERIC_TEXT pszPlayerName) 

long Uses CommandPlayerQ to prompt the VCP to 

GetRemainingPlayerTime supply its remaining play time. 

Currently, this always returns ZERO. 

(PGENERIC.TEXT pszPlayerName) 
bool 

SetAnnouncementAudioLevel 

(PCONTEXT_HANDLE_TYPE 
phContext, 
long lAudioLevel, 

DWORD dwZone, 
bool Persist) 

void 

SetOverhead 

(OVERHEADSTATETYPE OHState, 
long Channel, 

PGENERIC_TEXT pszPlayerName) 
bool 

SetPlayerSegment 

(PGENERIC_TEXT pszPlayerName, 
long lSegment) 

void 

UpdateSystemState 

(PCONTEXT_HANDLE_TYPE 

phContext) 

IFE Message Support 

Thi s S e rvic e 718 handles incoming IFE Messages using its overcast ProcessRequestQ 
thread 715 . In addition to the standard IFE messages, this class handles the following 
messages: FailedPlayer, VCPStatus, and VideoControl.. 

IFE Message Function Called Purpose 


Notifies this Service that a change to the 
system state has occurred. 


Transmits a message to the PESC-V via the 
Backbone NAU to identify which channel 
represents the overhead video source. All 
parameters are Input Parameters. 


Tells the VCP NAU to set the given 
pszPlayerName VCP to the selected lSegment. 
Returns FALSE if Segment value is invalid (> 
Oxff). 


Sets the Cabin Audio volume level. 

A value of - 1 for dwZone specifies that PA 
volume for all zones is to be set to the 
specified audio level. If Persist is set TRUE, 
this updates the database as well, making 
this a permanent setting. 
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IFB Message Function Called 

F ailedPlayer ProcessFailedPlayerQ 

SubProcessStart InitServiceQ 
VCPStatus ProcessVCPStatusQ 

VideoControl ProcessVideoControl() 


Purpose 

Returns to the caller the number of 
players and which ones are flagged as 
failed. 

Creates a PlayerConfiguration object 
and initialize its variables. 

Updates the VCPState (via 
PlayerConfiguration: :SetVCPState () ), 
updates the database and tell the 
MovieCycle Service of the changed 
status via an IFE_Message. 

Updates the named player's status as 
given in the message, and outputs it 
to the Status Window. 


Vid e o Announc e m e nt S e rvic e 


The VideoAnnouncementService class is derived from the CabinService class and 
contains several additional sets of functions that are used sporadically throughout the 
flight to support the playing of video clips, such as a safety video that must be 
broadcast to all passengers 1 17 at specific times during the flight. It provides the 
following functionality: creates a message for cabin configuration (cabin audio/ video), 
works with MovieCycleService to pause the movie cycle, starts an announcement tape, 
and talks to PESC-V 224b to control PA. 

The database tables affected by the VideoAnnouncementService Class are: Aircraft, 
PA Volume, VA Distribution, VideoMedium, and VideoSegment. 

Tabl e Nam e 

Aircraft 
PA- Volum e 
VA_Distribution 
Vid e oM e dium 
Vid e oS e gm e n t 

CAPI Support 
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The following table shows those functions that are used by CAP1.CPP call s 701 : 

VideoAnnouncementService Public Purpose 

Functions 

APIRESULT 

GetFirstVideoAnnouncementPlayList 

(PCONTEXT_HANDLE_TYPE phContext, 

PGENERICJTEXT 

pszVideoAnnouncementName, 

PGENERIC_TEXT pszPlayerName, 

VIDEOANNOUNCEMENTSTATUSTYPE 

*nState) 

APIRESULT 

GetNextVideoAnnouncementPlayList 

(PCONTEXT_HANDLE_TYPE phContext, 

PGENERIC_TEXT 

pszVideoAnnouncementName, 

PGENERIC_TEXT pszPlayerName, 

VIDEOANNOUNCEMENTSTATUSTYPE 

*nState) 

bool 

ReplaceVideoArmouncementPlayer 

(PCONTEXT_HANDLE_TYPE phContext, 

PGENERIC_TEXT pszAnnouncementName, 

PGENERIC_TEXT pszReplacementPlayer) 

bool 

ResumeVideoAnnouncement 
(PCONTEXT_HANDLE_TYPE phContext) 
bool 

StartVideoAnnouncement 

(PCONTEXT_HANDLE_TYPE phContext, 

PGENERIC_TEXT pszAnnouncementName) 

bool Stops the specified video 

Stop VideoAnnouncement announcement. 

(PCONTEXT_HANDLE_TYPE phContext, , 

PGENERIC_TEXT pszAnnouncementName) 


Starts the specified video 
announcement. 


Starts the PlayerConfiguration 
Object associated with the next 
Video Announcement to be played. 
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VideoAnnouncementService Public Purpose 

Functions 

Notifies this Service that a change 
to the system state has occurred. 

(PCONTEXT_HANDLE_TYPE phContext) 

IFE M e s s ag e Support 


void 

UpdateSystemState 


In addition to the CAPI support functions , thi s S e rvic e 717, IFE Message Support 718 
also handles incoming IFE Messages using its overcast ProcessRequestQ thread 715 . In 
addition to the standard IFE messages, this class handles the following messages: 

Function Called Purpose 

SetNextStateQ Sets the next state for the video 

announcement associated with 
the Player Configuration Object 
pPlayerConfig. 

PlayNextAnnouncementQ First, determines if the next 

announcement in the Video 
Announcement Play list requires 
installation of a new tape (i.e., 

Media ID). If so, then an 
Unsolicited message is 
transmitted to the GUI and the 
video announcement cycle is 
suspended. Once paused, the 
cycle must be restarted via 
either StartVideoAnnouncementQ 
or ResumeVideoAnnouncementQ . 

Performs the necessary Inits to 
get this Service going, including: 
SetAudioDistributionIrifo() 
SetVideoDistributionInfo() 
SetPlayerlnfoQ 

Sales Services 


SubProcessStar InitServiceQ 
t 


IFE Message 

Ack or Nak 

PlayNextVA 


Th e s e s e rvic e s control all the functions of In-Flight Service in which goods er- and 
entertainment are made available to passengers 117. Sales Services 482-486 are 
divided into the following Services: GamesService 482, MovieSaleService 483, 
CatalogService 484, DutyFreeService 486, and DrinkService 485. 
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The design structure of the Sales Service classes are similar to the Cabin Service 
classes, except that sales services 482-486 launch many more ProcessRequestQ threads 
715 to be able to service as many passengers 117 as possible. This is not necessary for 
the Cabin Services because they do not service individual passengers 1 17 7 ; they service 
5 the system as a whole. 


In addition to its overcast versions of the Service class virtual functions, SalesService 
Class includes its own virtual definitions within its children classes. This keeps the 
CAPI consistent in its calls: 

SalesService Virtual Function Purpose 

virtual bool Abstract to cancel an open order. 

CancelOrder 

(ID OrderlD) 

virtual ID Abstract to Create an order. 

CreateOrder 

(unsigned char *ProductCode, 
long Quantity, 

LRU.NAME Seat, 
unsigned char 
*EmployeeNumber, 
long IProductMap, 

MONEY AmountDue) 

virtual bool Abstract to schedule an Order for 

DeliverOrder Delivery. 

(ID OrderlD, 

GENERICTEXT 

EmployeeNumber) 
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SalesService Virtual Function 

virtual bool 
PayForOrder 

(ID OrderlD, 

MONEY AmountCash, 

MONEY AmountCredit, 
GENERIC_TEXT CurrencyCode, 
GENERIC_TEXT 
EmployeeNumber, 
GENERIC_TEXT 
AccountNumber, 
GENERIC_TEXT ExpirationDate, 
GENERIC.TEXT CardName, 
CREDITCARDS CardType) 

virtual bool 
RefundOrder 

(ID OrderlD, 

GENERIC_TEXT 
EmployeeNumber, 
bool RevokeProduct) 

virtual bool 
StartPipeThreadsQ 

virtual bool 

StartUpProcessThreadsQ 

SalesService also provides several 'gene 
sections that follow. 


Purpose 

Abstract to record the payment for an 
order. 


Abstract to Refund an order. 


Abstract to start the I/O with 
Transaction Dispatcher. 

Abstract to start ProcessRequestQ 
threads. 

2' sales functions, as shown in the sub- 


CAPI Support 


The following functions are called by CAPI functions. In the Sales Services 482 - 486 , all 
CAPI calls cause an update message to be built and sent to the applicable seat 44 ? 123 . 
so that it knows the status of its sales. 

SalesServiceClass Public Functions Purpose 

bool Removes the any Orderld records from 

BackOrderOut( the database. 

CONTEXTHANDLESTRUCT 

*pContextHandle, 

ID OrderlD) 
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SalesServiceClass Public Functions 

bool 

CloseSalesStore( 

ID StorelD) 

SERVICESTATUSTYPE 
Is ValidCreditCard( 
char *CardNumber, 
char *ExpirationDate, 
double CreditAmount, 
CONTEXTHANDLESTRUCT 
ContextHandle) 

bool 

OpenSalesStore( 

ID StorelD) 

IFE M es sag e Support 


Purpose 

Sets the status of the store to Closed. 

Verifies the type of card, expiration 
date and checksum according to the 
policy of this card type. 

Sets the status of the store to Open. 


The following functions are provided to support these IFE Messages for all Sales: 


IFE Message 

BackOut 


Cancel 


CompleteUpdate 


SalesService Function 

bool 

BackOrderOut( 

CONTEXTHANDLESTRUCT 

*pContextHandle, 

ID OrderlD) 

bool 

PrepareCancel( 
CONTEXTHANDLESTRUCT 
*pContextHandle , 
Seat_Message *pSeatMessage) 

void 

Process UpdateRequest( 
Seat_Message *pMsg, 
IfeldType nProcessID, 

Queue *pTransmitQueue) 


Purpose 

Removes the order from 
the database. This is 
usually due to an error 
during processing, rather 
than a customer request. 

Cancels an open order 
upon customer request. 


Collects revenue and 
movie or game lock 
information for a specified 
seat and returns the data 
to the SeatNAU. 


Delivery bool Prepares an order for 

PrepareDelivery( delivery. 

CONTEXTHANDLESTRUCT 

*pContextHandle, 

Seat_Message *pSeatMessage) 


IncrementalUpdate void 

Process UpdateRequestQ 


See CompleteUpdate 
message above. 
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IFB Message 

SalesService Function 

Purpose 

Payment 

bool 

Applies the provided 


PreparePayment( 

payment information to 


CONTEXTHANDLESTRUCT 
*pContextHandle , 
Seat_Message *pSeatMessage, 
ID *OrderID) 

the specified order. 

Refund 

bool 

Processes a refund 


PrepareRefund( 

request to return 


CONTEXTHANDLESTRUCT 

payment(s) to a customer 


*pContextHandle , 

and update inventory (if 


Seat_Message *pSeatMessage) 

needed). 


Movi e Sal es S e rvic e 4 83 


5 


Movie Viewing is a highly variable feature of the system. At the discretion of the airline, 
and subject to change from time to time, different video offerings are free to certain 
classes of passengers 117 , while others are chargeable. The Movies Sales Service 483 
controls this feature. The database tables affected by the VideoAnnouncementService 
Class are: Policy, Price. VideoMedium, VideoSegment, and VideoUse. 


Tabl e Nam e 

Policy 

Vid e oM e dium 

Vid e oS e gm e nt 

Vid e oU s e 


Derived from SalesService class, the MovieServiceClass provides the functions needed 
to process the sales of movies onboard. Like CabinService class, it provides its own 
ProcessRequestQ , GetMessageQ , PutMessageQ, etc. functions. 


10 


G API - Support 


The following overcast functions are called by their corresponding CAPI calls 701 : 
CancelOrderQ, CreateOrderQ, DeliverOrderQ , PayForOrderQ, and RefundOrderQ . 

I FE - M e ssag e Support 


A 
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In addition to the CAPI support functions, this S e rvic e lFE Message Support 718 also 
handles incoming IFE Messages using its overcast ProcessRequestQ thread 715 . 
Currently, all of the supported messages are supported using inline code that includes 
functions from the generic SalesService class along with the following: 

IFE Message Function Purpose 

Order CreateOrderQ See CAPI Support 

Gam e s R e ntal s S e rvic e 48 2 

Nintendo Video Games sire available for passengers to enjoy. To play them, a request 
must be made and often a payment is required. The Games Rental Service control s this 
capability. 482 uses the database tables GameDetail. Policy, and Price. 

Tabl e Nam e 

Gam e D e tail 

Policy 

Derived from SalesService class, the GameServiceClass provides the functions needed 
to process the sales of movies onboard. Like CabinService class, Itit provides its own 
ProcessRequest f!) 715. GetMessaae f 0 719. PutMessaae f 0 720. etc. functions. 

CAPI - Support 

The following overcast functions are called by their corresponding CAPI calls: 
CancelOrderQ, CreateOrderQ, DeliverOrderQ, PayForOrderQ, and RefundOrderQ. See 
SalesService class for details. 

IFE M es sag e Support 

In addition to the CAPI support functions , this S e rvic e 717. IFE Message Support 718 
also handles incoming IFE Messages using its overcast ProcessRequestQ thread 715 . 
Currently, all of the supported messages are supported using inline code that includes 
functions from the generic SalesService class along with the following: 

IFE Message Function Purpose 
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Order CreateOrderQ See CAPI Support 

Packag e Ent e rtainm e nt Functions 


Package Entertainment is a hybrid of Games and Movies Sales and is maintained 
within the MoviesSales class. It involves a one-time purchase to all entertainment 
services onboard. The Package Entertainment Functions may be used to control this 
5 | capability, but currently the SEAT NAU and CAPI.CPP calls 701 r oute Package products 
to either the Game Service or the Movie Service, based on the product code that is used. 
The followin g PackageDetail table is used to identify the components of a "Package". 

Tabl e Nam e 

Packag e D e tail 

Catalog Sal es 484 


10 


Purchasing goods through an electronic catalog is an enhancement provided by the 
system 100 . All functions that control it are kept in the Catalog Sales Service 484 . 
The following tables support the feature: Address. Order , and ShiopingRate. 


Tabl e Nam e 

Addr ess 

Ord e r, 

ShippingRat e 

Drink Sal es 48 5 


15 


Ordering drinks through the In-Flight Entertainment system 100 is provided. All 
functions that control it are kept in the Drinks Sales Servic e 485 . The following table 
supports the feature: Product 


Tabl e Nam e 

Product 


Duty Fr ee Sak e s 48 6 

Purchasing onboard duty-free goods through the In-Flight Entertainment system 100 
is provided. All functions that control it are kept in the Duty Free Sales Service 486 . 


j£ 
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The following tables support the feature: Cart. Cartlnventorv. Commitment, and 
Inventorying. 


Tabl e Nam e 

Cart 

Cartlnv e ntory 

Commitm e nt 


CAPI Calls 


5 


10 


All the application-level database functions are directly accessible via calls to the CAPI 
functions. These calls are available directly, or via the RPC server. Thus, any 
S e rvice service as well as any RPC GU e n t client can access the CAPI calls. 

CAPI.CPP 701 contains the actual commands that interface to the database 493 and 
perform the application duties (such as CreateOrderO. GetOrderfh etc.). CAPIJ3.C 702 
is the RPC S e rv e r server w hose functions are made available to RPC Cli e nt s clients (via 
CAPI_C.C). The S e rv e r server functions use the CAPI.CPP 701 calls to perform 
application duties. They are used together to make up this set of routines. In addition, 
the PAT GUI 426 can also access CAPI.CPP via APIINT.CPP and CAPI_S.C in the 
RPCCLNT.DLL. 


Acc es s G e ntrol Function s 


15 


Acc e s s Control Function s ar e us e d to validat e and dir e ct us e r acc e ss throughout th e 
syst e m. - Th e y includ e ID Card - par se r s , PIN validator s , and th e lik e . 


Tabl e Nam e 

Acc ess 

P e rsonn e l 
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Databas e Sch e ma 

The cabin file server database 493 i s s hown in Figur e 39 and stores the following types 
of information. This information is utilized by both the cabin file server Application 
application and the PAT GUI 426 and is described in greater detail below. 


10 


The cabin file server database 493 stores other line replaceable units in the IFE system 
100 , the products and services available to the passengers 117 , revenue due to the 
sales of products and services, system usage due to the flight attendants and 
passengers 117 , surveys offered to passengers 117 , the state of the cabin file server 
Application application . video announcements, and global attributes of the IFE system 
100 . Th e structur e (i. e ., tabl es , vi e ws, trigg e rs, r e lation s hip s , e tc.) of th e cabin fil e 
se rv e r databa se 4 93 i s sh e wn in Figur e 39, which i s maintain e d using a Microsoft 
Acc e s s ® R e lation s hip s tool. 


LRU Information 


The cabin file server database 493 provides storage for line replaceable unit 
15 information. This enables the cabin file server application to communicate with and/or 
control these other devices. Some line replaceable unit information is provided by the 
two data files that are generated by the ACS tool. 

_Line replaceable unit information is stored in the following tables: LRU, Member. 

PA Volume. PassengerMap. Set . and VideoPlaver. 


20 


S e at Transf e r 


Tabl e Nam e 

LRU 

M e mb e r 

PA_Volum e 

Pass e ng e rMap 

S e t — 

Vid e oPlay e r 
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All purchased goods and services, purchase summary information, complimentary 
service assignments, and movie lockout information is stored on a per passenger basis. 
This information may be swapped from one seat 123 to another seat to accommodate 
the occasion when a passenger 117 must be moved during a flight. Each passenger 
5 117 is represented in a PassengerMap table by a single record. This record contains 

the following pertinent information: 

Field Name Purpose 

SeatNumber Passenger seat 

number 

PassengerE) Passenger Identifier 

When a passenger 117 changes seats, the SeatNumber fields of the two records involved 
are swapped. Thus, all the information associated with the passenger 117 is not with 
the seat 123, but with their PassengerlD . 

10 

The viewing of any movie and/or the playing of any game can be locked out at any seat, 
usually at the request of a parent to prevent a child from seeing a certain movie or 
excessive game play. Each passenger 117 is represented in the PassengerMap table by 
a single record. This record contains the following pertinent information: 

Field Name Purpose 

SeatNumber Passenger seat 

number 

MovieLockoutMap Movie lockout bit map 

GameLockoutMap Game lockout bit map 

15 The MovieLockoutMap and GameLockoutMap fields are bit map fields whose bits 

correspond to individual movie and game titles, respectively. A movie or game is locked 
out when it's corresponding bit in this field is set to one. 


I Loss of communication with an seat display unit 433 122a is also recorded in the 
20 PassengerMap table. 
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Field Name Purpose 

SeatNumber Passenger seat number 

SeatCommSuccessCount # Successful communications 

SeatCommFailCount # Unsuccessful 

communications 


At the beginning of each flight, the SeatCommFailCount and SeatCommSuccessCount 
fields for each seat are initialized to zero. The SeatCommFailCount field is incremented 
for each first- time-failure encountered for the corresponding seat 123 (i.e., increment if 
fail <= success). The SeatCommSuccessCount field is incremented for each first-time- 
5 success encountered for the corresponding seat (i.e., increment if success < fail). These 
rules are enforced through triggers on these database fields. The seat 123 is considered 
bad if the SeatCommSuccessCount is less than the SeatCommFailCount. . 


Product and S e rvic e Information 


10 


15 


The cabin file server database 493 provides storage for product and service information 
(e.g., movie titles, viewing times, movie audio languages, game titles, audio 
entertainment titles, audio channels, etc.). This information is sent by the cabin file 
server application to the Seat Display Unit 43 3122a for each flight. This enables up-to- 
date information to be presented to the passengers 1 17 so they can know which 
products and services are available to them and at what cost on a per flight basis. 
Product and Service information is stored in the feHe wfollow MovieCvcle ing tables: 
AudioDetail. Cart. Cartlnventorv. GameDetail. IFE Service. Inventorying. 
MovieCvcleDetail. PackageDetail. Price. Product. ProductEffectivitv. Route. 

ShippingRate. Store. VideoMedium. VideoPlaver. VideoSeement. and VideoUse. 
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Tabl e Nam e 

AudioD e tail 

Gartl n v e ntory 
Gam e D e tail 
IFE_S e rvic e 
Inv e ntory Log 
Movi e Cycl e 
M e vi e Cyel e D e tail 
Packag e D e tail 

Product 

ProductEff e ctivity 

Rout e 

ShippingRat e 

Stor e 

Vid e oM e dium 

Vid e oPlay e r 

Vid e oS e gm e nt 

Vid e oU se 

Vid e o Gam es 

Video Game information is maintained in the GameDetail table, one record per 
Title/ EffectivityDate combination: 

Field Name Purpose 

Title The Game Title that is displayed on the seat display unit 

433122a 
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EffectivityDate The date on or after which this game information is 
effective. 

RouteType The flight route type during which this game is available. 

ProductCode Corresponds to a product code in the Price table for price 
lookups. 

P - rie es ar e controll e d via th es e fi e lds in th e- Pric e tabl e , on e p e r ProductCode/ RouteType 
c ombination: 


Fi e ld Nam e 

ProductCode 

RouteTyp e 

FreeMap 

Pricing 1 
Pricing2 
Pricing3 
Pricing 4 

Vid e o Programming 


Purpos e 

Corr e spond s to Gam e or Movi e Product s for s al e 

Th e flight rout e typ e during which thi s pric e appli e s 

Id e ntifi es- which zon es (id e ntifi e d in bitmap) off e r this 
product fr ee of charg e 

Pricing s tructur e for zon e 1 during thi s flight - rout e 
P - ricing s tructur e for zon e 2 during thi s flight rout e 
Pricing s tructur e for zon e 3 during 4 hi s- flight rout e 
Pricing s tructur e for zon e 4 during this flight rout e 


Video Game information is maintained in the VideoMedium table, one record per video 
program, one record per MediaTitle : 


Field Name Purpose 

MediaTitle The Game Title that is displayed on the seat display 
unit 13 3122 

ProductCode Corresponds to a product code in the Price table for 
price lookups. 

The IFE system 100 can inhibit the selectability of these video programs based on the 
date stored in the EffectivityDate of the VideoSegment table. Movie titles are associated 
with a specific flight route through the RouteType field of the VideoUse table. Prices are 
controlled via these fields in the Price table, one per ProductCode/ RouteType 
combination: 
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Field Name 

ProductCode 

RouteType 

FreeMap 

Pricingl 
Pricing2 
Pricing3 
Pricing4 
Movi e Cycl es 


Purpose 

Corresponds to Game or Movie Products for sale 

The flight route type during which this price applies 

Identifies which zones (identified in bitmap) offer this 
product free of charge 

Pricing structure for zone 1 during this flight route 
Pricing structure for zone 2 during this flight route 
Pricing structure for zone 3 during this flight route 
Pricing structure for zone 4 during this flight route 


Th e databa se tabl e s u se d in Movi e Cycl e ar e : 


Tabl e Nam e 

M e mb e r 

Movi e Cycl e 


S e t_ 


Vid e oM e dium 

Vid e oPlay e r 

Vid e oS e gm e nt 

Vid e oUs e 

The database tables used in Movie Cycle are: Member. MovieCycle, Set , Videomedium, 
VideoPlayer, VideoSegemnt, and VideoUse, 


5 Video sources such as video cassette player 227 or video reproducers (VR) 227 are 

assigned to a movie cycle through the Member and Set_ tables. Each VCP or VR 227 is 
stored in the Member field of the Member table. Each movie cycle is stored in the 
SetName field of the Set_ table. The following movie cycle information is stored in the 
database. 
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A movie cycle type is a predefined grouping of video reproducers 227 and movie titles. 
Movie titles are assigned to video reproducers 227 through the VideoMedium and 
VideoUse tables. The database 493 can store up to eight different movie cycle types. 
Information about each movie cycle type is stored in the MovieCycle table. A movie 
5 cycle can include from one to fifteen video reproducers 227 (i.e., one to fifteen records 
of the Member table can be associated with a single movie cycle in the Set table). 

The start time for a movie cycle is stored in the RelativeStartTime field of the MovieCycle 
table. It is stored in minutes relative to the time since movie cycle initiation at the 
primary access terminal 225. A between-cycle intermission time is stored in the 
10 IntermissionLength field of the MovieCycle table. It is stored in minutes and must 

exceed the time required to prepare the video reproducer 227 containing the longest 
playing tape for the next cycle (e.g., tape rewind). 

The end time of a movie cycle is the time in which the final viewing of a particular movie 
cycle ends. The number of viewings that can be scheduled for each movie cycle 
15 depends upon the length of a single viewing of the movie cycle and the flight duration. 
The length of a single viewing of the specific movie cycle can be calculated by adding the 
IntermissionLength field of the MovieCycle table to the SegmentRunTime field of the 
VideoSegment table for the movie with the longest run time in the specific movie cycle. 
The expected flight duration is stored in the FlightDuration field of the Flight table. 

20 Information about the state of a particular Video Reproducer 227 is stored in the State 
field of the VideoPlayer table. This information includes whether or not the video 
reproducer 227 is operational, whether or not the video reproducer 227 contains a 
tape, etc. 

The number of minutes before the start of each cycle can be calculated using the 
25 RelativeStartTime field of the MovieCycle table, the calculated length of the single 

viewing of the movie cycle, and the IntermissionLength field of the MovieCycle table. The 
number of minutes before intermission for the current cycle is stored in the 
RemainingViewingTime of the MovieCycle table. 

The number of minutes until the next viewing of a specific movie cycle is stored in the 
30 NextViewingTime of the MovieCycle table. The number of minutes remaining on the 

current viewing of the specific movie cycle is stored in the RemainingViewingTime of the 
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MovieCycle table. The number of minutes elapsed into the current viewing of the 
specific movie cycle is stored in the ElapsedViewingTime of the MovieCycle table. 

Packag e Ent e rtainm e nt 

A predetermined set of movies and/or games can be assigned to an airline-defined 
5 package. Package information is stored in the PackageDetail table. 

Audio Programming 

Audio programming (entertainment) can be distributed on a maximum of 83 mono 
audio channels, controlled by the AudioDetail table, one record per program. The title 
of each audio program is stored in the AudioTitle field. The channel of each Audio 
10 program is stored in the AudioChannel field. 


Languag e S e l e ction 

The VideoMedium table stores up to four different languages for a particular video tape 
(e.g., movies). These languages are displayed on the display screen 122 for passenger 
selection. The languages are stored in the LanguageCodel , LanguageCode2 } 

15 LanguageCode3 , and LanguageCode4 fields of the VideoMedium table. Each video tape 

must have one language designated as the default primary language (i.e., 
LanguageCodel must not be empty) but it can have up to three other languages. The 
relationship of the output configuration of the video players and available language 
configuration is stored in the VideoPlayer table. 


20 


Vid e o R e produc e r (VR) Control 


Information about each video reproducer 227 is stored in the VideoPlayer table. In 
order to "preview" the output of a particular video player on the primary access terminal 
screen, both primary access terminal tuners (audio and video) must be tuned to the 
proper channels. Video channel information for each video reproducer 227 is stored in 
25 the VideoRF__Channel field. Audio time- slot information is stored in the various time 
slot fields (i.e., LeftTimeSlotl y RightTimeSlotl , LeftTimeSlot2 , etc.). 


A video reproducer 227 can be reassigned for use during a video announcement. The 
MediaType field in the VideoMedium table distinguishes a video announcement from a 
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movie. The VideoUse table tracks which movie or video announcement is assigned to 
which video reproducer 227. When a video reproducer 227 is reassigned, the 
PlayerName field in the VideoUse table is modified. The playing status of each video 
reproducer 227 -is stored in the State field of the VideoPlayer table. 


5 


Ov e rh e ad Di s play Control 


Overhead monitors 162 can be assigned to a video source (i.e., video player 227) for 
movies. This information's stored in the OverheadAudioMap and OverheadVideoMap 
fields of the MovieCycleDetail table. 


R e v e nu e Informa tion 


10 


15 


The cabin file server database 493 provides storage for revenue information (e.g., credit 
card data, cash collection data, etc.) concerning the sales of products (e.g., duty free) 
and services (e.g., movies and games). When a passenger 117 uses a credit card to pay 
for movies or games, this information must be stored in the database so that it can be 
transferred to the credit card company. Likewise, when a passenger 117 uses cash to 
pay for movies or games, this information must be stored in the database 493 so that 
the IFE system 100 has a record of how much cash should be collected by the flight 
attendant. 
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The purpose of transaction processing is to maintain a record of monetary transactions 


for service and products. When a flight attendant is involved with an order placed by a 
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passenger 117 (e.g., order refunded, order placed at the PAT, etc.), then the flight 
attendant ID is stored in the FlightAttendant field of the Order_ table. 

Product/ S e rvic e Pricing 

Information about each product and service is stored in the Product table. Information 
about each package of goods or services is stored in the PackageDetail table. The 
pricing information for each product, service, and package is stored in the Price table. 
Prices can be altered according to the policy stored in the PolicyDescription field of the 
Policy table. For example, the policy may specify different service price data for movies 
and games offered in each seat class zone (e.g., first class) in the aircraft 111. 

Paym e nt M e thods 

Services and products may be paid by either cash, credit card, or a combination of the 
two. Cash and credit card payments are respectively stored in the CashTotal and 
CreditTotal fields of the Order_ table. Orders are comprised of sets of products or 
services of the same type. If the passenger 1 17 uses a credit card, the credit card 
information (e.g., passenger name, account number, etc.) is stored in the CreditCard 
table. 

Cash Paym e nt 

Cash transactions may be represented in up to 30 different currency types. 

Information about each currency type is stored in the Currency, table. Each aircraft 
111 has associated with it a base currency that is stored in the BaseCurrencyCode field 
of the Aircraft table. 

Cr e dit Card Paym e nt 

Passengers 1 17 may pay for products and services using any single card from the 
credit card types accepted by the airline. Information about each valid credit card type 
is stored in the ValidCardData table. The credit card payment made on a given order is 
stored in the CreditTotal field of the Order, table. This payment is recorded in the base 
currency type as specified in the BaseCurrencyCode field of the Aircraft table. 

Credit card numbers are validated against the standard number format and range for 
that particular credit card type. This standard number format is stored in the 
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ValidationPattem field of the ValidCardData table. Also, credit card transactions are 
validated against the credit limit specified by the passenger 117 for that particular 
credit card type. This credit limit is stored in the CreditLimit field of the ValidCardData 
table. In addition, each credit card is compared against the credit card numbers in the 
5 BadCreditCards table. This table may contain up to 10,000 records, for example. 

Transaction R e cords 

All transactions (i.e., service orders, product orders) processed by the system are stored 
in the Order_ table. The state of an order (open, paid, canceled, refunded) is stored in 
the State field of the Order_ table. For refunded orders, a duplicate order record is 
10 created with the AmountDue field, the CashTotal field, the CreditTotal field, and the 

Quantity field all set to negative amounts. Orders that are placed at the primary access 
terminal 225 also have a corresponding entry in the PAT_History table. A new record is 
generated for the OrderHistoiy table for each change to the State field or the Delivered 
field. 

15 The following information is maintained for each order: 


Table 

Field 

Description 

PassengerMap 

SeatNumber 

seat number 

Product 

ProductDescription 

service or product ordered 

Order_ 

Quantity 

quantity of service or product ordered 

CreditCard 

all fields 

credit card information for credit card 
orders 

Price 

UnitPrice 

unit cost of service or product ordered 

Order_ 

AmountDue 

total cost of service or product 
ordered 


I FE - Sy s t e m Shutdown 

Prior to shutdown of the IFE system 100 , a message is displayed on the primary access 
terminal 225 if the database 493 contains any open transactions from the current 
flight. The number of open orders for the current flight is always displayed in the 
20 status window on the primary access terminal 225 . This is calculated by counting each 
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order in the Order_ table (for the current flight) whose associated State field is set to 
"Open”. 

Purcha se Summary 

A running tabulation of all expenses incurred for each passenger during the current 
flight can be displayed on the seat display unit 43 3122a or seat display 122. Each 
order is associated with a specific passenger 117 via the PassengerE) field of the Order_ 
table. The total cost of each order is stored in the AmountDue field of the Order_ table. 
Total expenses incurred for a particular passenger 117 is the sum of the total cost of 
each order placed by the specific passenger 117. 

Sal es S e rvic e Function Support 

The following subsections describe selected database interactions that occur when the 
corresponding functions in the SalesServiceClass classes are executed. 

Canc e lOrd e rQ 

Upon cancellation of any cash passenger product and/or service order that has not 
been paid, the State field of the Order_ table is changed from "Open” to "Cancelled". If 
the service (i.e., video game or movie) is revoked from the passenger 117, then the 
ProductRevoked field in the Order_ table is set to TRUE. 

Ga s h - Coll e ction List 

A list of orders can be generated for which cash collection is to be made in-flight. 
Information related to each order is as follows: 


Table 

Field 

Description 

PassengerMap 

SeatNumber 

seat number 

Product 

ProductDescription 

product or service 
ordered 

Order_ 

AmountDue 

amount due 


Orders can be listed by service type and/or by general service zone. The service type of 
an order (i.e., game, movie, package) is stored in the ServiceType field of the Product 


98-PS-039 



-371- 


table. The general service zone of the passenger 117 that placed the order is stored in 
the SetName field of the Set_ table. 

Product D e liv e ry List 

A list of orders can be generated for which delivery is to be made in-flight. Information 
5 related to each order is as indicated above. Orders can be listed by service type and/or 
by general service zone. 

Complim e ntary S e rvic e 

Complimentary service for movies, games, and/or entertainment packages may be 
offered to individual passengers or to the entire aircraft 111. For individual 
10 passengers, an order is placed in the Order_ table for each passenger 117 receiving a 
service that is complimentary, the PayCurrencyCode field is set to "Free" and the State 
field is set to "Paid". The order is then associated with the record in the Passenger Map 
table where the SeatNumber corresponds to the specific passenger 117. 

To provide complimentary service for the entire aircraft 111, all entertainment (movies, 
15 games, packages) must be complimentary. A single order is placed in the Order, table: 
The PayCurrencyCode field is set to "Free" and the State field is set to "Paid". The order 
is then associated with the record in the PassengerMap table where the SeatNumber 
field is set to "Allseats". The FreeServicesMode field of the Aircraft table is set to TRUE. 

Curr e ncy Exchang e 

20 The system 100 can support up to thirty forms of currency. Currency information is 
stored in the Currency, table. Exchange rate information is stored in the Exchange 
table. Currency exchange rate calculations can be performed that support a display 
with up to four decimal places. The number of decimal places to display is stored in the 
DisplayPrecision field of the Currency, table. 

25 Each currency is associated with a Policy table enby to specify how to convert from one 
currency to another. For example, the policy for converting to US dollars might be to 
round to the nearest penny, or nearest whole dollar if the airline does not wish to deal 
with change. The policy actually points to the applicable stored procedure to perform 
this function. 
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Sy s t e m Usag e Information 

The cabin file server database 493 provides storage for system usage by both the flight 
attendants and passengers 117 . 

Flight Att e ndant Activity 

5 The cabin file server database 493 keeps track of each time the flight attendant logs on 
and off. Additionally, the flight attendants may also enter flight identification 
information (e.g., flight number, destination, etc.) which is stored in the cabin file 
server database 493 . Flight attendant activity is stored in the following tables: Access, 
Flight, and Personnel. 

T a bl e Nam e 

Acc es s 

F l ight 

P e r s onn e l 

10 Each time a user (i.e., employee) logs in to the IFE system 100 , this login information is 
stored in the Access table. It is also added to the Personnel table (once for each user) if 
a predefined set of valid users does not already exist. If a predefined set of valid users 
is preloaded into the Personnel table, then each user that tries to login can be validated 
against this pre-defined set of valid users. 

15 An access level for each user is stored in the AccessLevel field of the Personnel table. 
This access level can be used to direct the user's access throughout the system 100 , 
effectively controlling what they can see or do. For example, a Service Person should 
not have access to Revenue Modification functions. 

When users are required to insert a magnetically encoded card during the logon 
20 process, the card is encoded with the user ID (EmployeeNumber field), pin number (PIN 
field), and grade level ( AccessLevel ). This information is stored in the Access table for 
each login. This information is also added to the Personnel table (once for each user) if 
a pre-defined set of valid users does not already exist. If a predefined set of valid users 
is preloaded into the Personnel table, then each user that tries to login can be validated 
25 against this predefined set of valid users. 
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In the case where the card read is not successful, the user must manually enter the 
user ID, pin number, and grade level. This information is stored in the Access table for 
each login. This information is also added to the Personnel table (once for each user) if 
a predefined set of valid users does not already exist. If a predefined set of valid users 
is preloaded into the Personnel table, then each user that tries to login can be validated 
against this predefined set of valid users. 

Pas se ng e r Activity 

The cabin file server database 493 also logs system activity (i.e., passenger usage of the 
system 100 from the seat display unit standpoint). The database 493 stores how much 
time each seat spent on each movie, on each game, and on each audio selection. This 
allows the airline to see how passengers 117 are using the system 100 . 

Passenger activity is stored in the following tables: PassengerStatistics. 

Tabl e Nam e 

Pass e ng e rStatistics 

Pas se ng e r Statistics 


The following passenger statistic information is stored in the database 493 : 


Table(s) 


Pield(s) 


Definition or Comment. 


PassengerMap 


SeatNumber Each passenger is associated with their 

PassengerE) seat number. 


Member Set 


Member Each seat number is associated with one 

SetName class (e.g., first class, coach, etc.). The 

seat number is stored in the Member 
field of the Member table. The class is 
stored in the SetName field of the Set_ 
table. 


PassengerStatistics Statlmage Time spent viewing movies by title: Each 

movie watched and length of time spent 
watching each movie is stored here as a 
Binary Large OBject (BLOB) which can 
hold up to 2GBytes of data if disk space 
allows. 
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Table(s) 


Field(s) Definition or Comment. 


PassengerStatistics Statlmage Time spent listening to entertainment 

audio by title: Each audio entertainment 
listened to and the length of time spent 
listening to each audio entertainment is 
additionally stored here (BLOB) . 

PassengerStatistics Statlmage Time spent playing games by title: Each 

game played and length of time spent 
playing each game is additionally stored 
in the here (BLOB). 


Pa s s e ng e r Surv e y Informa tien 


The cabin file server database 493 provides storage of passenger survey information. 
Passengers 1 17 at each seat 123 can elect to participate in the survey. The database 
493 records each result (i.e., passenger's answer) to each survey taken so that this 
information can be made available to the airline. Passenger survey information is 
stored in the following tables: Survey. SurvevAnswer. SurvevAnswerKev. and 
SurvevOuestion. 


Tabl e Nam e 

Surv e y 

Surv e yAnsw e r 

Surv e yAn s w e rK e y 

Surv e yQu es tion 

The results of each survey taken (or same survey taken multiple times) by each 
passenger are stored in the SurveyAnswer table. Survey results may be off-loaded 
using the Data Offload approach discussed above. The name of the survey is stored in 
the Survey table. The corresponding questions contained in the survey are stored in 
the SurveyQuestion table. All possible answers (i.e., six multiple choice answers) for 
each survey question are stored in the SurveyAnswerKey table. 

Application Stat e Informat ion 

The cabin file server database 493 provides storage for application state information. 
This is useful in cases where there is an interruption of aircraft power while the 
application is running. Storing this information in the database 493 allows the system 
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to resume operation where it left off. There may be over 100 processes running at any 
given time. Each process can store as much information as needed in the Data field of 
the PowerRecovery table in order for the process to know where it should continue once 
power is resumed. The Data field is defined as a Binary Large OBject (BLOB). 

Pau se / R e sum e Int e ractiv e S e rvic e s 

The state (e.g., start, pause, stop, init) of the IFE system 100 is stored in the IFE_State 
field of the Aircraft table. Products and/or services ordered by the passenger 117 are 
stored in the Order_ table (as well as at the seat display unit -133122a for backup). 

This enables the IFE system 100 to start from where it left off once passenger 
entertainment and interactive services are resumed. 

Vid e o Announc e m e nt Information 

The cabin file server database 493 provides storage for Video Announcement 
information. This information may include attributes such as video announcement 
titles, overhead audio, overhead video, and whether in-seat displays 122 are 
overridden. Video Announcement information is stored in the following tables: 

VA Distribution. VideoMedium, VideoSegment. VideoPlaver, and VideoUse. 

Tabl e Nam e 

VA_Distribution 

Vid e oM e dium 

Vid e oS e gm e nt 

Vid e oPlay e r 

Vid e oUs e 


Vid e o Announc e m e nt 

Video Announcement information is stored in the VideoMedium table. Examples 
include boarding announcements, safety announcements, short subject programs, etc. 
Each Video Announcement has more specific information stored in the VideoSegment 
table. 


98-PS-039 



-376- 


Attributes for each Video Announcement are stored in the VA_Distribution table. 
Attributes include, but are not limited to: if the announcement is heard on the overhead 
audio and in which zone ( OverheadAudioMap field, where each bit in the field 
represents a zone), if the announcement is viewed on the overhead video and in which 
5 zone (OverheadVideoMap field, where each bit in the field represents a zone), if the 
announcement (audio and video) overrides whatever is currently being viewed at the 
seat ( InseatOverrideMap field, where each bit in the field represents a zone), or be 
available for in-seat viewing (default) and in which zone. 

Video Announcements (audio and video) are available for in- seat viewing (default). This 
10 means that the passenger 117 has the option to select the video channel on which the 
video announcement is being played. Video Announcements can also be set to override 
in-seat viewing. In this case, the IFE system 100 causes the overridden in-seat 
displays in a specified zone to select the video channel on which the video 
announcement is being played, and the passenger 1 17 is unable to turn off the in-seat 
15 video display 122. 


Each Video Announcement is assigned to a particular source (i.e., video player) through 
the VideoUse table. Attributes for each video player are stored in the VideoPlayer table. 
The default volume level for the PA speakers is stored in the DefaultPA_AudioLevel field 
of the Aircraft table. The volume level for the PA speakers can be different for each 
20 zone. This is stored in the AudioLevel field in the PA_Volume table. 


Ov e rh e ad Display - Gontrol 

Overhead monitors 162 can be assigned to a video source (i.e., video player 227) for 
video announcements. This information is stored in the OverheadAudioMap and 
OverheadVideoMap fields of the VA_Distribution table. 


25 


Global Attribut e Informa tion 


30 


The cabin file server database 493 provides storage for global attribute information (i.e., 
information that can be accessed by any service). Examples may include the current 
state of the IFE system 100, the base currency, and the default PA audio. IFE system 
global attribute information is stored in the following tables: Aircraft. Airline. Airport. 
Country. Flight, and Route. 
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Tabl e Nam e 

Aircraft 

Airlin e 

Airport 

Country 

Plight 

Rout e 

Flight Information 

The following flight information is pre-loaded and stored in the Route table, one record 
per known route: 


Field 

FlightNumber 

FlightDuration 

DepartureAirport 

ArrivalAirport 

RouteType 


Description 

flight number assigned to this flight leg 
estimated flight duration in minutes 
departure airport code 
arrival airport code 

route type to determine which services are 
available on this route 


When the flight attendant enters a FlightNumber and RouteType at the primary access 
terminal 225, the corresponding flight information (i.e., FlightDuration , ArrivalAirport , , 
and DepartureAirport) is found in the Route table and presented at the primary access 
terminal 225 and stored in the current record of the Flight table. The DepartureDate 
and DepartureTime are determined based on when the weight-off-wheels signal is 
received. This date and time' is then stored in the WeightOffWheelTime field of the 
Flight table to calculate movie cycle and other sales times. 


IFE -- Tool Support 


The following IFE data is configurable in order to tailor the IFE functionality for a 
particular airline. This tailoring is done using the IFE Tools software. 


98-PS-039 



-378- 


(a) IFE function data configuration ID: Version field of the DB_Version table. 

(b) For each video game: (1) The cost of each video game is specified in the UnitPrice 
field of the Price table. This cost can be altered based on the PolicyDescription field of 
the Policy table. A video game can be offered for free in a given zone by setting the 

5 associated bit in the FreeMap field of the Price table to 1. (2) The type of video game is 
stored in the GameType field of the GameDetail table. (3) The activation date is stored 
in the EffectivityDate field of the GameDetail table. 

(c) For each movie: (1) The cost of each movie is specified in the UnitPrice field of the 
Price table. This cost can be altered based on the PolicyDescription field of the Policy 

10 table. A movie can be offered for free in a given zone by setting the associated bit in the 
FreeMap field of the Price table to one. (2) The length of each movie is stored in the 
SegmentRunTime field of the VideoSegment table. (3) The activation date is stored in 
the EffectivityDate field of the VideoUse table. 

(d) For each aircraft seat class zone: whether video games and movies are pay or free is 
15 addressed in items (b) and (c) above. 

(e) For each aircraft seat class zone: which passenger survey is available. 

(f) Logical seat groups (e.g., general service zones, duty free zones) are specified in the 
Member and Set_ tables. Seat numbers are stored in the Member field of the Member 
table. Zones are stored in the SetType field of the Set_ table. 

20 (g) For each route type: Titles to appear in the video game menu, audio menu, and 

| movie menu of the seat display unit 433 122a . Titles to appear in the video game menu 
can be limited according to route type. The titles are stored in the Title field of the 
GameDetail table. The route type is stored in the RouteType field of the GameDetail 
table. Titles to appear in the audio menu can be limited according to route type. The 
25 titles are stored in the AudioTitle field of the AudioDetail table. The route type is stored 
in the RouteType field of the AudioDetail table. Titles to appear in the movie menu can 
be limited according to route type. The titles are stored in the MediaTitle field of the 
VideoMedium table. The route type is stored in the RouteType field of the VideoUse 
table. 
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(h) Currency exchange rates are stored in the ExchangeRate field of the Exchange table. 

(i) The primary access terminal display currency is stored in the PAT_DisplayCurrency 
field of the Aircraft table. 

(j) For each flight number: Arrival/ departure city pairs, flight duration and route type. 
5 Each flight number is associated with a specific route. The route is specified by the 

FlightNumber and Leg fields of the Route table. The arrival/ departure city pairs for a 
given route is respectively stored in the ArrivalAirport and DepartureAirport fields of the 
Route table. The scheduled flight duration for a given route is stored in the 
FlightDuration field of the Route table. The calculated flight duration (e.g., based on tail 
10 wind, etc.) for a given route is stored in the FlightDuration field of the Flight table. The 
route type of a given route is stored in the RouteType field of the Route table. 

(k) Movie cycle attributes are specified in the Cabin File Server Executive Extensions 
Software Design Document . 

(l) Video announcement titles are stored in the MediaTitle field of the VideoMedium 
15 table. Video announcement lengths are stored in the SegmentRunTime field of the 

VideoSegment table. 

(m) The video announcement cabin speaker default volume is stored in the 
DefaultPA_AudioLevel field in the Aircraft table. This volume cannot be changed during 
a flight. During database initialization, a record for the PA__Volume table is created for 

20 every PA zone (as specified by the LRU table). The AudioLevel field in each record of the 
PA_Volume table is initialized to the DefaultPA_AudioLevel . The video announcement 
cabin speaker default volume can then be modified for each PA zone (e.g., passengers in 
the PA zone over the engine may need a louder default volume). The new volume is 
stored in the AudioLevel field of the PA_Volume table. 

25 (n) The video reproducer 227 assigned to a particular video announcement is stored in 

the PlayerName field of the VideoUse table. The video reproducer 229 assigned to a 
particular movie is stored in the PlayerName field of the VideoUse table. 

(o) Product pricing data is stored in the UnitPrice field of the Price table. Product 
effectivity data is stored in the EffectivityDate of the ProductEffectivity table. 
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(p) Accepted credit card types (i.e., Vi s a. Di s cov e rV ISA. DISCOVER , etc.) are stored in 
the CardName field of the ValidCardData table. Accepted charge limits are stored in the 
CreditLimit field of the ValidCardData table. This charge limit is defined by the airline. 

(q) The airline name is stored in the AirlineName field of the Airline table. 

(r) The number of movies in a particular package is stored in the MovieQuantity field of 
the PackageDetail table. The hours of game play is stored in the GameQuantity field of 
the PackageDetail table. Additional package details (e.g., which games/movies are in 
the package) are also stored in the PackageDetail table. 

GaMa The primary access terminal 225 must perform certain coordinating functions 
prior to being able to operate with the cabin file server R amfe iaao268 successfully. A 
System Initializer establishes the cabin file server hard drives as shared devices with 
the primary access terminal 225. synchronizes its system date and time with the date 
and time of the cabin file server 268, and turns on the LCD’s backlight so the user can 
see what's going on. The System Initializer. INITSYS.EXE. performs these functions at 
boot time. This program includes the source file INITSYS.CPP. 

Primary access terminal Stand Alone Utilities 4£S are PAT-resident utilities that are 
needed between runtimes fi.e.. between flights!. They are used by Service Personnel to 
manage data and system behavior. 

A Data Offloader is provides so that specific data is offloaded from the aircraft 1 1 1 for 
the purpose of revenue collection and system performance evaluation. At the end of 
each flight, the NT event logs are archived on the cabin file server hard disk. Passenger 
Statistics information, passenger survey results, and Transaction records are stored in 
the cabin file server database 493 for later retrieval. 


This database information is stored for up to forty flight legs. The number of flight legs 
is stored in the FliahtID field of the Flight table. FliahtE) is simply a counter which is 
incremented after each flight. The Data Offload approach discussed previously 
describes the Data Archival. Data Offload and Disk Space Management processes. 

The following paragraphs describe the additional functionality associated with the Data 
Offload process, in the utility OLUTIL.EXE. 
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The flight number for a test flight always begins with a "9". This enables a custom 
trigger, FLIGHT ITRIG.SOL, to purge just test flight data fi.e., flights beginning with a 
"9”) from the database at the beginning of a subsequent flight. The purge is 
automatically performed at the beginning of the next flight rather than at the end of the 
5 test flight so that the information can remain in the database long enough to offload the 
data for trouble-shooting purposes but not so long that credit card data may be 
compromised. However, if the Data Offload process is manually initiated at the end of 
the test flight, then the test flight data is purged at this time. 

Archived data (i.e., previous flight leg) can be off-loaded on a per-flight basis. All credit 
10 card transaction data is encrypted using PKZIP.EXE (an industry-standard third-party 
file-compression utility). PKZIP was chosen because it provides excellent file 
compression ratios and allows for password encryption of the compressed data. 


At the start of each flight, the Offload field in the Flight table for the specific flight is 
initialized to one. Once a particular flight has been off-loaded, the Offload field in the 
15 Flight table is set to zero (i.e., flight data is tagged). It is possible to automatically 

specify the off-load of all non-tagged data (i.e., all flights with Offload field set to one). It 
is also possible to manually specify the off-load of data for a specific flight. 

An operator is able to disable the Watchdog driver 410. DISWDQG.EXE is used to 
disable the hardware Watchdog by issuing an IQCTL Disable command to the Watchdog 
20 Driver 410. 


Cabin file server Runtime Utilities 425 are programs that are used once per flight, 
either at the beginning or at the end. As a result, they are part of the application and 
are maintained along with the cabin file server Executive Extensions. 


S e at Di s play Unit Databas e Build e r 

25 SDU_BLDR.EXE, the seat display unit database builder, is used to develop a download 
file to be downloaded to all seats 117. The download file is comprised of product and 
entertainment information that is subject to change based on the contents of the cabin 
file server database 493. 


When flight information is entered by the Flight Attendants at the primary access 
30 terminal 225, the SDU_BLDR on the cabin file server 268 is initiated. The GUI 426 
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calls SDU Builder via the CAPI to extract the information from the cabin file server 
database 493 that is pertinent to the current flight. This information is used to create 
the download file (sdu_data.dnl) that is sent to each seat 123 on the aircraft 111. 

The purpose of sdu_data.dnl is to provide current information (i.e., entertainment, 
pricing, etc.) from the database 493 to the passenger seats 123. The creation of the 
download file triggers the Seat NAU to notify each seat that a new download file exists. 
Each seat then requests the file and applies the portion of the download file that is 
applicable to their programming (i.e., first class seats don’t read the information in the 
download file applicable to coach seats 123). 

Ev e nt Log Archiv e r 

CFSLOGS.EXE is the main C++ executable associated with the archival of the event 
logs. It runs on the cabin file server 268 and is initiated during the data archive 
process. Cfslogs.exe is responsible for dumping the NT event logs of the cabin file server 
268 to the hard disk using a unique archive file name. This file name is passed to 
cfslogs.exe as an input parameter. 

P o int of Sal e s Offload e r 

DUMP_POS.EXE is the main C++ executable associated with offloading Point of Sales 
data. It runs on the cabin file server 268 and is initiated during the data offload 
process. Dump_pos.exe is responsible for writing the archived database information for 
a given flight to the various FLTSALES.CSV files on the hard disk. The flight ID is 
passed to dump_pos.exe as an input parameter. 

Archiv e Purg e r 

PARCHIVE.EXE is the main C++ executable associated with the purging of archive data. 
It runs on the cabin file server 268 and is initiated as part of the effort to manage the 
disk space on the cabin file server 268. Parchive.exe is responsible for deleting both 
the Archive file and the Offload file from the hard drive. Both of these files are passed 
to parchive.exe as input parameters. 
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Dump Pa s s e ng e r Statistics 

DUMPSTAT.EXE is the main C++ executable associated with offloading Passenger 
Statistic data. It runs on the cabin file server 268 and is initiated during the data 
offload process. Dumpstat.exe is responsible for writing the archived database 
5 information for a given flight to the paxstats.csv files on the hard disk. The flight ID is 
passed to dumpstat.exe as an input parameter. 


Th e primary-acc ess t e rminal Ex e cutiv e Ext e nsion 

Th e primary acc es s t e rminal Ex e cutiv e Ext e n s ion -se t of routin e s which, tog e th e r with 
th e Common Ex e cutiv e s oftwar e , forms th e g e n e ric application for th e primary acc e ss 
10 t e rminal -2 25 - - It includ e s NAUs, Librari es , Driv e r s , and Runtim e Utilitie s as d e scrib e d 
h e r e in. 

A discu s sion follow s- r e garding th e N e twork Addr ess abl e Units that r e sid e on th e 
primary acc ess t e rminal 225. Th e primary acc es s - t e rminal 225 N e twork Addr e ssabl e 
Unit program 4 09 function and data paths ar e shown in Figur e 4 0. Th e primary acc ess 
15 t e rminal NAU 4 09 provid e s th e int e rfac e b e tw ee n th e PAT GUI 4 26 or th e Application 
S e rvic es and th e uniqu e d e vic es- attach e d to th e Primary Acc ess T e rminal 225. Each of 
th e s e d e vic es i s controll e d via it s own Virtual LRU s e t of function s . In addition, most of 
th ese d e vic es- communicat e via th e s am e I/O chann e l, -- th e PI Mux. 


Common Software Libraries 

20 

The following common software libraries of functions and utilities are used throughout 
the primary access terminal and cabin file server applications. 

The Database Utilities. DBUTILS.CPP are commonly used by all database applications. 
They use the SQL commands (recognizable as starting with db...(f . such as dbexitfl 
25 dbresultsfl etc.): 

Audio Tun e r - VLRU Function Th e Audio Tun e r VLRU allow s control of audio 

chann e l s e l e ction s for flight att e ndant pr e vi e wing 
via th e PAT GUI. Purpose 
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Audio Tun e r VLRU Fimction Th e Audio Tun e r VLRU allows control of audio 

chann e l se l e ctions for flight att e ndant pr e vi e wing 
via th e PAT GUI. Purpose 


Card Reader 
VLR U CheckResultsQ 


G UI - Monitor 
YLR U UodateStatsl ) 


PAT -A /LRU FailureExitO 


Th e Card R e ad e r VLRU coll e ct s and forward s data 
from th e card r e ad e r, to b e u s ed by th e Acc e ss 
Functions and Sal es S e rvic e s' 

Function s . Continuously loops calling dbresultsO 
to get the results of the prior SOL call for this 
process until they have all been obtained. If there 
are errors, it displays function text for tracing. 

No LRU i s actuall y- as s ociat e d with this VLRU. 

Th e GUI Monitor VLRU' s duty is to s tart th e GUI 
and e nd th e GUI as appropriat e . Updates the 
statistics of the given table for the given process. 

Th e PAT VLRU r es pond s to loopback m e ssag e s 
from th e CFS Te s tPort NAU via Eth e rn e t for BIT 
functiona f &y r - It log s communication failur es 
b e tw ee n th e PAT and th e CFS. It control s th e 
BITE and COMM -L ED s on th e front of th e PAT, 
lighting th e m to indicat e failur e s. Standard exit 
function, displays the error before calling dbexitf). 


P ri nt e r Th e Print e r VLRU p e riodically qu e ri es th e Control 

Vi^ JTransactionLoaControlf) C e nt e r Print e r for its s tatus and provid e this 

s t a tu s a s an un s olicit e d m ess ag e to th e PAT GUI. 


PAT. EXE contain s th e primary acc ess t e rminal NAU progra m-409 . Th e primary acc ess 
t e rminal NAU program 4 09 includ es th e following primary compon e nt s : 


PAT. CPP SelectlntoControlf) Th e MainQ Program 


The event logging functions. EVENTLOG.CPP, RETRYSYS.CPP. are used exclusively in 
5 SYSMON.EXE and POWERDWN.EXE. They each call EventLog’s ProblemReportf ) 

subroutine (which is recursive!) which calls EventLoa::WriteHAILoa() which eventually 
uses NTs RevortEventO to record the information. 

The set SOL Error and Message Handlers. HANDLERS. CPP includes two routines used 
bv functions such as ARCHIVE.CPP CREATEDB. CPP DUMP POS.CPP. INITDB.CPP and 
10 SUP BLDR.CPP to handle SOL informational and error messages: err handler f) and 
msa handled). These functions are identified to the SOL code using 
dberrhandleferr handler ) and dbrnsahandlefnisa handler) respectively. 
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GUMNITOR. CP P int err handler 
input DBPROCESS *dbproc. 


input int severity, 
input int dberr. 
input int oserr. 
input char *dberrstr, 
input char *oserrstr) 


Th e GUI Monitor VLRU Cla s s Builds a DB- 
LIBRARY error message containing both a 


database error idberr and dberrstrl and an 
operating system error foserr and oserrstr). 
echoes it to stdout and fif oserr is not 
DBNOERR) uses Utility Class: :LoaEvent(i to put 
this info into the event log. See 
UtilituClass::LoaEventfl for severity definition. 


Returns INT EXIT if the database process 
pointer dbproc is no good. Otherwise. 

INT CANCEL. 


CRDRDRVL.CF P int msa handler 
input DBPROCESS *dbproc 


input DBINT ms 


input int msgstate 


input int severity. 
input char *msgtext) 


Th e Card R e ad e r VLRU Clase lf the severity is 
reater than zero, it logs it to the event lo 


otherwise it simply builds and displays the 


message. It always returns ZERO. 


ueues include OUEUE.CPP and OPAIR.CPP. A Queue is a dynamic list of pointers to 


elements of any type which must wait for sequential processing such as an output 


ueue. The actual elements are not stored in the Queue. A OPair is a set of two 


ueues used for related purposes, for example one for Input and one for Output 
associated with a named pipe pair or a serial port. 

This class is used to create and maintain all Queues in the Control Center software to 
buffer message traffic. The first or top or head position of the queue is identified as 
element number zero 101. 

Queues made with this class are considered to be "thread safe". That is. multiple 
threads can access these queues concurrently. These queues generate a signal when 
data is written to them. One can choose whether the queue should signal with only an 
event handle or with a semaphore as well. This class allows one to create and control 
the size of for number of elements in) vour queue, move elements in and out of the 


aueue. and allow multiple users or readers to manipulate a single queue. 


The following member functions are used to create and control the size of (or number of 
elements in) the queues. 
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TUNRVLRU.CP P Oueue Th e Audio T - un e r VLRU Class Purpose 

class Function 


PATVLRU. CPP The 

Constructors: 

Queued 

Queue (ULQNG Size) 


PRNTRVLR.CP P short 

GetCountl) 


Th e PAT main VLRU Clas s lnitialize the queue. If no 
Size (or if Size = 0) is given, then the Queue is not 
delimited and can grow to the capacity of the system 
(defined by constant LONG MAX). If Size is given, 
the queue is limited to contain no more than Size 
elements by having all Put functions display "Queue 
Overflow" to stdout and returning TRUE when an 
attempt is made to exceed the limit. 

Th e Print e r VLRU Class Retums the number of 
elements currently in the queue. 


PRNTRSTT. CPP ULONG Th e Print e r VLRU’ s Statu s Sub - Cla ss Retums the 

GetSizel) preset maximum size of the queue. If the value 

returned is zero, the size is not delimited. 


PIMUX.CPP bool 

SetSize 

(ULQNG Size) 


Th e PI MUX VLRU Cla ss Allows one to increase the 
maximum size of the queue. Returns FALSE if 
Queue was already defined as undelimited or if the 
new size is less than the previous size. 


The Selective Style member functions are used when the priority of the queue elements 
is controlled. 


PINTRFCE. CPP Queiie Th e bas e class for th e Tun e r VLRU, Card R e ad e r 

class Function VLRU and PAT VLRU s Purpose 

Main Program 

MainQ r e gist e rs with th e Sy s t e m Monitor 4 12 and launch e s a PIDispatch obj e ct to op e n 
up communications b e tw ee n th e m e ssag e proc e s s or 4 0 4 and th e transaction di s patch e r 
4 21 . It - calls PIDispatch: :$tartItUp () - to initialize th e VLRU s , on e e ach. It also launch e s 
th e Session^ thr e ad s — Mamfl waits to di e , e ith e r by r e c e iving a Pr e e ess Stop command 
from Sy s t e m Monitor 4 12 , or e ls e it sl ee ps for e v e r until int e rrupt e d. It calls 
shutltDownf) to clos e all th e VLRUs down with a SubProc ess Stop command and e xit 
grac e fully. 
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FromMuxPut O v oid * 

PeekNthl 

long N) 


Plac es a m es sag e on th e FromMux qu e u e . Returns the 
contents of the Nth element of the list but doesn't 
remove it from the queue. If none, returns NULL. 


FromMuxGet O bool 
PutNtN 

void *Element. 
long N) 


R e ad s a PI_M e s s ag e from th e FromMux qu e u e and 
conv e rts - it t e- a PAT_M ess ag e . Inserts the Elements 
pointer into the queue at position N. If N+ 1 is greater 
than the current number of elements on the queue, 
then the Element's pointer is placed at the end of the 
queue instead of at N. Returns FALSE if. 


The FIFO Style member functions are used when a First-In-First-Out FIFO style queue 
is desired. 


Function 


R e ad s and e ncod es for transmi ss ion - a PlJVl es sag e from 
the ToMux queue. Furoose 


FromMuxSemaphoreHand 
lef jv oid * 

Get!) 


R e turn s th e handl e for this qu e u e Returns the element 
at the top of the list. If none, returns NULL. Same as 
GetNthfO). 


FromMuxSemaphoreHand 
iet iv oid * 

PeekO 


Returns the handl e for thi s contents of the element at 
the top of the list, but doesn't remove it from the 
queue. If none, returns NULL. Same as PeekNth/OL 


P l- Mux - VLRU 







10 


15 


20 


25 



void ‘Element) 


PutNth/Element, 0). Returns FALSE if 
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} 


by way of -fe h e Eth e rn e t n e twork 22 8 from CAPIJ5.C calls 7 84 in th e S e rvic e s. e x e 
p rogram 4 77 running in th e cabin fil e s e rv e r 268. Th e CGUIS e rvic e ::Proc e ssR e qu e st() 
thr e ad s 775 rout e m e ssag es to and from a local - tran s action dispatch e r 4 21a. Th e 
APIINT::CMSToGui Qu e u e 77 4 r e c e iv e s m e ssag es from th e local transaction di s patch e r 
4 21a and from a r e mot e tran s action di s patch e r 4 21b. M es sag e s s e nt from th e 
transaction dispatch e r s-4 2 la^ 4 21b, ar e forward e d to an 

APIINT::CAPIM e ssag e InThr e adProc e dur e (): 7 8 5 which rout es th e m es sag e s to th e CAPI 
M es sage S e rvic e Window 48 1. 

Th e PAT - GUI 4 26 - eannot b e communicat e d to via Nam e d Pip es b e cau se it - i s a Window s 
application, and must th e r e for e communicat e u s ing standard Window s m e ssag e s. Th e 
CAPI M e ssag e Handl e r is - a se t of routin es within th e CAPI Library 4 27 which provid e s a 
bridg e b e tw ee n th e IFE m e s s ag e s and th e GUI Window s application. Inst e ad of 
communicating via Nam e d Pip e s dir e ctly with th e GUI, Unsolicit e d M es sage s 780 utiliz e 
Nam e d Pip e s into a M e s s ag e- S e rvice Window 7 8 0, In ord e r for th e GUI 4 26 to b e abl e 
te r e c e iv e th e m, it mu s t hav e alr e ady op e n e d or s tart e d a Window capabl e of r e c e iving 
t h i s- typ e of m e s s ag e in th e background u s ing th e appropriat e CAPI Library call s . 

Any Windows Us e r - Int e rfac e that n ee d s to communicat e with th e transaction 
dispatcher ( s ) 4 21 of th e primary acc es s t e rminal 225 and/ o r - eabin fil e se rv e r 26 8 , or 
who n ee ds to acc ess th e CAPI call s- m - th e SERVICE.EXE program of th e cabin fil e 
se rv e r 26 8 n ee ds to link in and us e th e RPCLIENT.DLL library 4 27 which contain s t he 
following fil e s: 


Allow multiple users or readers to manipulate a single queue. 


Function 


DllmainQ and Vi s ual Ba s ic Application Int e rfac e 
Routin es Purpose 


Queue { 

ULQNG Size, 

bool useSemaphore = 

TRUE) 


Th e CAPI's RPC Cli e nt Support Routin e s Set 
useSemaphore = TRUE if the queue is going to be 
referenced by more than one 'reader' or thread. 
Otherwise, set it to FALSE or don’t supply it. When 
set to TRUE, the constructor calls CreateSemaphore to 
establish the semaphore handle, and assigns a 
Resource Count equal to the Size, which means that if 
you specify a queue of 10, at most 10 threads can 
access it at once. 
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Fuacfciom 


HANDLE 


etEventHandle 


the signal handle for use Drimarir 


with WaitF orSinaleObiect!) to halt a thread until 


something is placed in the queue. 


HANDLE 


etSemavhoreHandle 


the semaphore handle for use primarily with 


WaitForSinaleObjectO to halt a thread until somethin 


is placed in the queue. Use only when useSemaphore 


is TRUE in constructor. 


the queue so other 


’readers' can't alter its contents. If the queue is 
already locked (in useL this call waits until it is no 
longer locked. The Queue member functions each 
perform a lock and unlock when they update the 
queue, but there are times when you need to perform 
several queue functions while keeping total control of 
the queue. In this case, use the Lock 0 function. 


Unlock 


control of the 


ueue so others can add or remove elements. Use 


only if you previously used Lockf) to isolate queue 


[iXE 
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GUI Application Calls 

CAPI provid e s a compr e h e nsiv e s e t of functions that allow th e applieat 4 on - to p e rform in 
th e following functional cat e gori es : 

CAPI Maint e nanc e Functions 


5 


The short class Queue Pairs maintains a set of two queues that are related. Typically 
one is used for Input and one is used for Output. Their names, however, are Lefty and 
Rightv. 


Initializ e lnt e rfac e Oueue R e l e a se lnt e rfac e Purpose 

class Function 

Qp e nCommunicat - ionPat Clo se CommunicationPath T hese constructors simply 

hThe Constructors: construct the two Queues, Lefty and Rightv. 

Qpcdri 

ULQNG Size. 

bool bUseSemaphoreh 

Ovairi 

ULQNG Size! 

C urr e ncy Function s 


Conv e rtCurr e ncy G e tFirstCurr e ncy 


G e tN e xtCurr e ncy 


10 


Flight Information Functions 
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S e tlFEStat e 

G e tRout e Data 

G e tN e xtAirport 

G e tN e xtCountry 

G e tAircraftData 

Queue& LeftO 
Oueue& Riahtf) 


G e tFir s tRout e 

G e tRout e DataFromFlightL e g 

G e tAirportData 

G e tFir s tAircraft 

G e tFir s tLRU 

Returns a pointer to Queue Lefty. 
Returns a pointer to Queue Rightv. 


G e tN e xtRoute 

G e tFirstAirport 

G e tFirstGountry 

G e tN e xtAircraft 

G e tN e xtLRU 


The RpcClientClass, RPCCLNTC.CPP contains all of the functionality needed for an 
application to communicate with the Fileserver RPC Server via the Cabin Application 
Programming Interface (CAPI). To use it, the Create f) call should be executed. Then a 
call to GetContextHandlef ) provides the I/O handle for communications. 


RpcClientClass class Function 

bool 
Create () 


bool 

Deletel) 


bool 

GetContextHandlel 

output PPCONTEXT HANDLE TYPE 

pphContext) 


G e tLRUDat a bool 
ReleaseContextHandle ( 
output PCQNTEXT HANDLE TYPE 
phContext) 


Purpose 

Creates and initializes an RPC Interface 
channel between an application and the 
RPC Server process using 
RvcNsBindinalmvortBegind 
Returns TRUE if successful, FALSE 
otherwise. 

Terminates the RPC Session with the 
server process. 

Returns TRUE if successful, FALSE 
otherwise. 

Retrieves a database context handle 
from the server process via an RPC 
channel previously opened using 
Created Calls the Capi c.c 
InitializelnterfaceQ function to connect to 
RPC. Returns FALSE if none. 

G e tR e mainingFlightTim e Retums a 
database context handle which was 
previously obtained by a call to 
GetContextHandled 
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RpcClientClass class Function Purpose 

Returns FALSE if none. 

P e rsonn e l and Acc e ss Function s 

G e tAcc es sData G e tFir s tAcc e s s G e tFirstP e rsonn e l 

G e tN e xtAcc e ss G e tN e xtP e rsonn e l G e tP e rsonn e lData 

I s Logg e dln LogP e rsonn e lln Le gP e r s onn e lQut 

Play e r and M e dia - Functions 


5 


The System Monitor Interface. SYSMNNTR.CPP is a set of routines that is used by any 
process that is under the control of SYSMON.EXE for shutdown purposes. This 
Constructors class has three constructors available for use: SusmonlnterfaceClassO is 
not used. SusmonlnterfaceClassfParentPTocess id. EventHandlel. 
SusmonlnterfaceClass/ParentProcess id. MessaeeOueue) 
SusmonlnterfaceClassfParentProcess idl. 


10 


ParentProcess id is used to identify the process in all communications with SvsMon 
(see WriteToSvsMonO 1. The other parameters are used to control the method of 
shutdown for the given process. If the process prefers to hear about it using an event, 
it can pass the EventHandle to be used when shutdown is needed. If the process 
prefers to hear about it via a message queue, it can pass the Queue ID in. 


15 Each Initialization process must first create a SvsmonlnterfaceClass object and then 
register communications with Svsmon using SusmonInterfaceClass::Reaistern. This 
calls ConnectSustemMonitord to create handles to two Named Pipes (input and output! 
to use to talk to the System Monitor. It then creates an IFE Message and sends it to 
Svsmon via WriteToSvsMonO. Finally. ReaisterO launches two threads to manage the 
20 named pipes with CreateSustemMordtorThreadsO. 


CreateSvstemMomtorThreadsO launches two communication threads who in turn call 
the actual I/O function: InoutThreadlnterfaceO calls ReadFromSvsMonO. 
OutputThreadlnterfaceO calls HeartBeatSusMorU l ReadFromSusMonD continuously reads 
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HeartBeatSusMonf) continuously issues a pulse message to Svsmon. to let it know that 


this process is alive. 

WriteToSusMonO is used to send any message to the System Monitor via the output 


named pipe. It uses IFE Message: :PutData() to do it. 


Anytime a message is received in ReadFromSusMonfL ProcessReauestO is called. This 
simply parses out any ProcessStop message and calls Shutdown 0 to continue. All other 


messages are ignored. 


ShutdownO cares about how this class was constructed. If an event handle was given, 
it sets this event to announce the shutdown to the host process. If a message queue 
was given, it forwards the ProcessStop message to the queue so the host can shutdown 
in a more orderly fashion. If neither of these was given, it halts the process with a 
ProcessExitd 

A Timer Utilities file, TMDCLLBC.CPP, contains a class timedCallback that is used to 
schedule activity in regular intervals. The user first creates a function to be called 
when a 'timeout' occurs by declaring it as long (*timedCallbackFun) (timedCallback 
*Entru); This function must return the number of ticks to wait until the next call 
should be invoked, or Zero to stop the re-queueing. 


Public timedCallback Fumcftious 


Purpose 


timedCallbackl } 


Constructs a callback using a default 'do- 
nothing' function. This allows one to create 
arrays of timedCallback objects and define 
the callback function later by use of 
member setFunf). 


timedCallbackl 

input timedCallbackFun SomeFun) 


Constructs a real-time clock callback to be 
used for later calls to queued and cancelfl 
SomeFun is the user-defined function to 
call when a timeout occurs. 


timedCallbackl ] 


the callback before 


it goes out of scope. 


cancell 1 


G e tFir s tPl a y e rCancels 'this' callback if it is 
queued, but retains the object for 
subsequent queueing. 
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Public timedCaMtoack Functions 


Purpose 


G e tN e xtMovi e Cvcl eint 

isOueuedl) 

G e tPlay e r S tat e v oid 
aueuei input long Delta) 


G e tR -e mainingPlav e rTim e void 
setFunlirwut timedCallbackFun 
SomeFun) 


G e tN e xtPlay e r Retums 1 if 'this' callback is 
queued, 0 otherwise. 

G e tPlay e r T yp e FromNam e Oueues the 
callback to be called after the specified 
number of invocations of tickfl Delta =- 0 
cancels the callback. Queue!) is 
automatically called each time the user's 
timedCallbackFunction is invoked. 


aueueO can be used to change the interval 
of an already queued callback. 

G e tVCPCount Redefines the callback 
function to be used for ’this' callback as 
what's contained in SomeFun. 


R e plac e Movi e Cycl e Plav e r static void R e p i ae e Vid e oAnnounc e m e ntPlav e r Advances 
tickO the time by one tick. As a result, queued 

callbacks may time-out and are then 
invoked from within tickfl Normally not 
used externally, this is maintained by the 
timer thread that was launched by the 
constructor. 


The General Utilities include UTLTYCLS.CPP. The UtilitvClass Class provides a general 
interface to the following generic utility functions. Many of these functions are declared 
as STATIC, which means that you can use them without creating an object of 
UtilitvClass, just by calling them with the class name in front, such as 
UtilitvClass: :bin2 Ascii! 0x2 f, &Hi &Lol 
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S e tAnnounc e m e ntAudioL e v e l UtilitvClas 

s Public Function 

S e tPlav e rS e gm e nt static void 
bin2Ascii 

(input unsigned char Hex, 
output unsigned char*Hi, 
output unsigned char*Lo) 

Star t Movi e Cvcl e unsigned char 
BuildNetworkAddress 

(input unsigned char *cpBuffer, 
output unsigned char 
*cpNetworkAddress, 

input DeviceHandleiType DeviceHandler) 

StopMovi e Gvcl e bool 

ConnectNetworkResource 

(input char *LocalName, 
input char *RemoteName) 

Vid e oPr e vi e w static unsigned short 
ConvertAsciiToBin 

(input unsigned char*bvAscii) 

Point of Sal e Function s 


S e tMovi e Gycl e Updat e Rat e Purpose 


S e tVid e oAnnounc e m e ntZon e Converts a 
binary hex value into a two byte ASCII 
character representation. 

e.g.. Hex = 0x2F, *Hi = '2' *Lo = 'F. 


StartVid e oAnnounc e m e nt Receives a 
character buffer of input data and 
creates a network address, returning it 
as an unsigned character. 
DeviceHandler defines whether the data 
is from ARCNET or RS-422. 

The length of the address is returned. 

If ZERO, no address was made. 

StopVid e oAnnounc e ment Connects the 
WINDOWS NT Network Resource 
specified by RemoteName to the drive 
specified by LocalName. 

Returns FALSE if any errors are 
encountered and connect fails. 

Takes 2 ASCII characters and returns 

them as unsigned binary. 

e.g., by ASCII = M 2F", returns 0x2F. 
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G e tFirstSurv e y 

G e tN e xtSurv e y 

G e tSurv e yAnsw e rData 

G e tSurv e yQu e stionlmag e 


G e tFirstSurv e yAn s w e r 

G e tN e xtSurv e yAn s w e r 

G e tSurv e yNam e 

StartSDUDatabas e Proc ess 


G e tFir s tSurv e yQu es tion 

G e tN e xtSurv e yQu e stion 

G e tSurv e yQu es tionData 


Un s olicit e d M es sag e S e rvic e Functions 

StartM e ssag e S e rvic e StopM e ssag e S e rvic e Pau se M ess ag e S e rvic e 


Vid e o Pr e vi e w Function s 

static unsigned char 
CorwertAsciiToBin 

(unsigned char AsciiChar) 

static bool 

CreatelfeldConversionMapl) 


static bool 

CreatelfePuncConversionMavl) 


bool 

GetFirstReaistru Value 

(input char *pszKevName, 
output char *pszValueName, 
input LPDWQRD dwValueNameLen, 
output LPDWQRD lpdwType, 
output LPBYTE lpbData, 
output LPDWQRD lpcbDatal 


Takes a single ASCII char and returns a 
single unsigned binary char, 
e.g., AsciiChar = 'F, returns OxOF. 


Initializes the IfeldMap data structure. 
For each entry in the Ifeld Type 
definition, a corresponding text string is 
written to the map. This data structure 
is used in conversions between process 
enumeration values and text values. 
Always returns TRUE. 

Initializes the IfeFuncMap data 
structure. For each entry in the 
IfeFunction Type definition, a 
corresponding text string is written to 
the map. This data structure is used in 
conversions between process 
enumeration values and text values. 
Always returns TRUE. 

Retrieves the name and data associated 
with the first value contained in the NT 
Registry that matches the registry 
keyname. 

Returns FALSE if unsuccessful. 
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bool 

GetNextReaistru Value 

(output char *pszValueName, 
output LPDWORD dwValueNameLen, 
output LPDWORD IpdwType, 
output LPBYTE lpbData, 
output LPDWORD lpcbDatal 

bool 

GetReaistruD Word 

(input char *lpszKeyName, 
input char *lpszValueName, 
output DWORD *lpdwValue) 

bool 

GetReaistruInfo 

(output CStringArrav *RegValueArravl 
bool 

GetRegistru String 

(input char *lpszValueName, 
output LPBYTE lpbData, 
output LPDWORD lpcbData) 

static bool 
IfeFuncToText 

(input IfeFunctionType nlfeFunction, 
output PGENERIC TEXT pszIfeFuncText) 


static bool 
IfeldToText 

(input IfeldType nlfeld, 

output PGENERIC TEXT pszIfeldText) 

static IfeFunctionType 
JfeTextToFunc 

(input PGENERIC TEXT pszIfeFuncText) 


After calling GetFirstRegistruValued 
this function can be called to retrieve 
subsequent registry value names and 
data. 

Returns FALSE if unsuccessful. 


Retrieves a DWORD value from the 
Registry into lpdwValue. 

Returns FALSE if unsuccessful. 


Retrieves all registry information by 
iterating through the registry key 
values, returning it in an array of 
strings. 

Returns FALSE if unsuccessful. 

Retrieves a string in lpbData 
corresponding to the input parameter 
ValueName. 

Returns FALSE if unsuccessful. 


Converts the IFE Function Message 
identifier contained in the nlfeFunction 
input argument into a text string 
representing the same enumeration 
name. 

Returns FALSE if unsuccessful. 

Converts the IFE Process /Thread 
identifier contained in the nlfeld input 
argument into a text string representing 
the same enumeration name. 

Returns FALSE if unsuccessful. 

Returns the corresponding 
Enumeration value for the Text String 
contained in pszIfeldText from the 
IfeFunctionType Type definition. 

If none, returns NoDestination. 
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static IfeldType 
IfeTextToId 

(input PGENERIC TEXT pszIfeldText) 

static void 
LoaEvent 

(input IfeldType nProcessId. 
input WORD wCategorv. 
input DWORD dwErrorCode. 
input char *pszFormat, input ... ) 

bool 

SetReaistru Confia Value 

(input char *ModuleName, 

input REGCONFIGINFO *ConfigInfo) 

bool 

SetReaistru String 

(input char *lpszKevName. 
input char *lpszValueName, 
input char *szString) 


Returns the corresponding 
Enumeration value for the Text String 
contained in pszIfeldText from the 
IfeldType Type definition. 

If none, returns NoDestination. 

This is the call-level interface to the 
WINDOWS NT event log. This takes the 
passed variables and develops a series 
of strings using nrintftoszFormat ara , . 
arq, ara) style, then forwards the 
developed string to RevortEventd 

This function is used by a process to 
register its Unit Id, Part Number, and 
Revision number to the WINDOWS NT 
Registry. 

Returns FALSE if any errors are 
encountered. 

Writes specified value and string data 
into specified registry key under 


Returns FALSE if any errors are 
encountered. 


HKEY LOCAL MACHINE. 


The Discrete Library, DISCRETE. LIB, contains the UTILITY. LIB Library plus the 
following. The WinRUtilClass class contains simple utilities for use with WinRT drivers: 


WinRTUtilClass Functions 

void 

Build WinRTDeviceName 

(output LPSTR szDeviceName. 
input LPSTR szDeviceNumber 

DWORD 

Get WinRTDetnceNumber 

(input LPSTR szDriverName. 

output PUCHAR szDeviceNumber, 

input LPDWORD lpdwDeviceNumberBufSize) 


Purpose 

Returns the full WinRT 
device name from a null- 
terminated device number. 


Uses null-terminated 
DriverName to look-up 
WinRT device number string 
in the registry. 


‘ Returns the value returned 
by its called 

ReaOueruValueExf) function. 
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It is fed into the WinRT Preprocessor to create DISCRETE. CPP, which is compiled into 


the DISCRETE. LIB library. The DiscreteDriverClass controls the system discretes. 


which are used to control peripherals such as LED indicators. 


Closes the Discrete WinRT device if it is open. 









class obj e ct us e d in th e sy s t e m. It t 
r e c e iv e IFE M e ssag e s from a r e gist e i 
4 31 (in th e primary acc e s s t e rminal 
m ess ag es ar e rout e d to APIINT' s CM 
5 CAPMessagelnThreadProcedureO ca 

UNSLCTDM.CPP - Unsolicit e d_M e ss 

Th e Unsolicit e d_M e ssag e Class 78 0- 
APIINT.CPP routin es 783: - It includ i 
put to tho se m e mb e rs. Th e custom 
10 ar e di s cu sse d b e low. 


LCD Vid e o - Hopkins VLCD - 102 


15 


Control of th e LGP -vid e o d e vic e is m 
actual hardwar e driv e r r e gi s t e r e d a s 
function s us e d by th e application to 
This driv e r - wa s provid e d by Hopkin e 
mu s t supp o rt both VGA output (for 
functionality. 


VIDEO.DLL i s compris e d of th e folio 


V10 - 2:RT bool 

GetVTRDiscrete 

(VTR DISCRETE TYPE 
VTRdiscreteChoicel 

I2C.RT bool 

IsPATO 


20 


Th e s e fil e s ar e pr e- proc e ss e d with W 
availabl e to th e application program: 


Function DWORD 

QpenDiscretesO 
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long PCV_FitVideo 

(longnXl, 

long nYl, 

long nSiz e X, 

long - nSiz e Yl DWORD 

ReadldO 


long - RCV Freeze Video/ K J CHAR 
ReadlnputDiscretesf) 


bool PCV_ GctPreuiewData 

(long *X, 
long *Y, 
long *XSiz e , 
long *YSiz e , 
long - ^Brightn e s s , 
long *Contra s t, 
long *Tintl UCHAR 
ReadOutputDiscretesO 

long PCV Initializef l bool 
SetLCDbackliaht 


(bool bOnOffl 


long PCV_SetColor 

(short nColor, 

short nColorValu e l bool 

SetLED 

(LED TYPE LEDchoice. 
bool bOnOffl 


Di s play n vid e o window on th e scr ee n with th e 
vid e o -s cal e d to fit in th e window. 
nXl, nYl ar e scr ee n coordinat es for - upp e r l e ft 
com e r of - window, 

nSiz e X, and nSiz e Y ar e th e window e xt e nt. 
R e turns: — 0 alway s . Reads discrete input I/O 
port to obtain this LRU id and stores it in the 
form: 01 lOfiik where f=l if CFS. f=0 if PAT: iik 
is the LRU id 000-111 (0-71. In this form the 
bvte mav be used as an ARCNET address. 


If successful. ERROR SUCCESS is returned. 

Fr ee z es th e vid e o imag e . 

R e turns: 0 always. Returns a bvte 
representing the state of the input discretes. 

R e turn s th e vid e o pr e vi e w s e ttings in th e 
provid e d variabl e addr e ss es . S ee 
PCV_SetPreviewData(). 

R e turn s : TRUE always. Returns a bvte 
representing the state of the output discretes. 


Initializ e s all VLCD - 102 compon e nts: 

Op e ning th e "vied 102" driv e r, initializing all 
th e PC Vid e o and Pix e l r e gist e rs, e tc. 

R e turn s : — 1 for succ ess . 0 for failur e . T ums 
the LCD backlight on or off. Returns the state 
of the backlight prior to this function call. 

Adj us t - th e brightn es s, contra s t OR hu e . 
nColor s e l e ct s which color attribut e is 
modifi e d. nColorValu e is th e n e w color 
s e tting. 

R e turns: - 0 always. T urns the specified LED on 
or off. Returns the state of the LED prior to 
this function call. 
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bool PCV^SetPreuiewData 

(long X, 
teng-¥, 
long - XSiz e , 
long YSiz e , 
long Brightn e ss, 
long Contrast, 
long Tintl bool 
SetVTRDiscrete 

(VTR DISCRETE TYPE 
VTRdiscreteChoice. 
bool bOnOffl 

long PCV_SetVideoFormat 

( s hort nFormat R JCHAR 
WriteOutputDiscretes 

(UCHAR ucOutputMask) 


E s tabli s h e s th e vid e o pr e vi e w window, wh e r e 
X and Y ar e th e starting coordinat es , XSiz e 
and YSiz e ar e th e h e ight and width of th e 
window, and Brightn e ss, Contrast and Tint 
control thos e f e atur e s. 

R e turns: FALSE if failur e . Asserts or de-asserts 
the specified VTR discrete. Returns the state 
of the discrete before this function call. 


Choo se s a vid e o format bas e d on nFormat: 
CF_PAL, CFrNTSC or CF_SECAM. 

R e turns: 0 always. Sets the output discretes 
according to the specified mask. Returns the 
state of the output discretes before they were 
changed by this function. 


A message library MESSAGE. LIB provides the means of moving data from one place 
and format to another without needing detailed understanding of the protocols involved. 
In general, all messages transmitted within the control center are of the type 
5 IFE Message. Therefore, a class called IFE Message is used to translate information 
into and out of this message type. Similarly, many messages enter the control center 
from the ARCNET devices, so to support them the ARCNET Message Class is made. 
Instead of requiring the user to start with an ARCNET Message and convert it to an 
IFE Message, the ARCNET Message is a superset of IFE Message. In this wav, the 
10 ARCNET Message contains the additional functions to manage the translations, and 
the migration from one form to another is nearly transparent. 


15 


For example, when raw data is read into MP.EXE from ARCNET. it is put into a new 
ARCNET Message object and passed to MessaaeToPioeProcessorO that treats this 
message as an IFE Message to send it to the appropriate NAU. The NAU uses its own 
flavor of IFE Message (Seat Message, for example! to read the data (via its own 
NAUGetMPf) 1 and from that point forward, the IFE message is treated more specifically. 
No special handling is needed to affect this change. By the time the message finally 
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reaches its ultimate destination process, the message class functions are used to deal 
with the actual bytes of the messages. These functions are described below. 


5 


The IFE Message class IFMSSAGE.CPP is the base class for all IFE message processing. 
A hierarchy exists such that each derived class implements specifics for its data 
processing. This makes translating data formats transparent to application 


programmers. 


long Unfr ee z es th e vid e o imag e . 

PCV UnFreezeVideof U FE Message R e turn s : 0 alwavs. Purpose 
Public Function 


Th e driv e r, VLCD102.SYS - is compris e d of th e following s ourc e fil e s: 


V102INIT.C iFE Message 

(IFE MESSAGE DATA 
*p!feMessagePata) 


P e rforms th e initialization - logic for th e video 
ehip rThis constructor prefills the local 
IfeMessageData with the raw 
plfeMessagePata. 


¥402_I2C.C v irtual void 
GetAddress 

(char *pAddress) 


Supports th e I2C protocol and 
hardwar e . Returns the Address data, (e.g., 
"SPU POIA"!, from the Address member found 
in the IfeMessagePata. 


VLGP102.C bool 

GetData 

(Queue *p!nputOueue) 


Handl es th e IQCTL support for this 
driverr lnitializes the IfeMesagePata structure 
of an IFE Message object with data from the 
Queue. The address of an IfeMessagePata 
structure is read from the specified queue, the 
data is copied into the IFE Message class. 

The IfeMessagePata structure read from the 
input queue is then Peleted. 

Returns FALSE if fails to get data. 


Th e s y s t e m 100 is construct e d in a modular fram e work, and is d e sign e d to e xpand to 
s upport various aircraft 111 configuration s: Sy s t e m coniiguration - information - is 
10 d e fin e d in an off - lin e configurabl e databa se . Syst e m configuration support tools 

provid e th e- capability to g e n e rat e databa se information, which is download e d to - th e 
appropriat e sy s t e m lin e r e plac e abl e units. Th e lin e r e plac e abl e unit s s tor es- databa se 
information in non - volatil e m e mory, and r e v e rts to d e fault databas e information wh e n 
th e y d e t e ct - n e wly download e d data inconsist e nt with th e phy s ical aircraft configuration, 
15 or - wh e n a databa se download i s unsucc e ssful. 
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Th e flight numb e r for a t es t flight always b e gins with a "9". This e nabl e s a custom 
trigg e r, FLIGH - T_.ITRIG.SQL, to purg e just t e st flight data (i. e ., flight s b e ginning with a 
"Q") from th e databa se at th e b e ginning of a subs e qu e nt flight. Th e purg e i s 
automatically - p e rform e d at th e b e ginning of th e n e xt flight rath e r than at th e e nd of th e 
5 t e st flight so that th e information can remain in th e databas e long e nough to offload th e 
data - for troubl e-s hooting^urpos e s but not s o long that cr e dit card data may b e 
c om p romis e d. How e v e r, if th e Data Offload proc ess is manually initiat e d at th e e nd of 
th e t es t flight, th e n th e t es t flight data i s purg e d at this tim e . 

Archiv e d data (i. e ., pr e vious flight l e g) can b e off load e d on a p e r flight ba s i s . All cr e dit 
10 card tran s action da t a - i s e ncrypt e d u s ing PKZIP.EXE (an industiy standard third - party 
fil e- compr e ssion utility). PKZIP wa s- eho se n b e cau se it - provid e s e xc e ll e nt fil e 
compr e ssion ratio s and allows for - pa ss word e ncryption of th e compr e ss e d data. 


15 


At th e s tart of e ach flight, th e Offload fi e ld in th e Flight tabl e for th e sp e cific flight i s 
initializ e d to on e . Onc e a particular flight ha s b ee n off - load e d, th e Offload fi e ld in th e 
Flight tabl e is s e t to z e ro (i. e ., flight - data is tagg e d); It i s po ss ibl e to automatically 
s p e cify th e off - load of all non - tagg e d ^ data (i. e ., all flights with Offload fi e ld se t to on e ). It 
is al s o possibl e to manually sp e cify - th e off - load of data - for a s p e cific flight. 


20 


An - op e rator i s abl e to di s abl e th e Watchdog driv e r 4 40 . DISWDOG.EXE i s u se d to 
di s abl e th e hardwar e Watchdog by issuing an IOCTL Disable command to - th e- Watchdog 


bool 

GetData 

(HANDLE hlnPine. 
ULONG *pBvtesRead) 

virtual IfeldType 
GetDestinationl) 

IfeFunctionType 

GetlfeFunctioni) 


void 

GetLruInfo 
(char *pLruInfo) 


Does a ReadFilef) on the specified handle and 
uses the data read to populate the 
IfeMessageData structure contained in this 
instance of the IFE Message class. 

Returns FALSE if fails to get data from Pipe. 

Returns the Destination data found in the 
IfeMessageData data member. 

Returns the IfeFunction element of the 
IFE MESSAGE DATA structure associated 
with this IFE Message. 

Returns the LRU information from the 
IFE Message. 
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bool 

GetLruTime 
(char *pszLruTypel 


void 

GetMessaaeData 

(BYTE *pData. 
WORD *wDataLen) 

virtual long 
GetMessageLengtH) 

CString 

GetNetworkAddressO 


virtual IfeldTvpe 
GetSourcel) 

UnsolicitedMessageType 

GetUnsolicitedMessagel) 

void 

Log(int nMessageDirection, 
IfeldTvpe nProcessId, 
char *pszDataFormat) 


Copies the data contained in the LRUType 
field of the IfeMessageData structure 
contained in this IFE Message into the 
location specified by the input argument 
pszLruType. 

Returns FALSE if pszLruType is a null 
pointer. 

Copies the data field of this IFE Message 
object into the pData argument. The number 
of bytes copied is written to the wDataLen 
argument. 


Returns the MessageLength data member 
value. 


Retrieves the network address from the raw 
data buffer of an IFE Message. 
GetNetworkAddress determines the location of 
address information in the Raw Data buffer 
based on the destination ID. Address 
information is converted from Binary to ASCII 
if necessary then placed into a CString which 
is returned to the calling function. 

Returns the Source data found in the 
IfeMessageData data member. 

Returns the value contained in the 
UnsolicitedMessage field of this IFE Message 
object. 


Formats a text string containing pertinent 
message information and writes it to standard 
output. 

MessageDirection can be set to LoglnpMsg or 
any other value to indicate whether the log 
should say ’Received 1 or Transmitted 1 , 
respectively. Processld is simply added to the 
Log string along with the IFE Message data. 
The DataFormat is used to determine which 
fields are used. If null, only the Process Id, 
Function, Destination Id, Source Id and 
Address are output to stdout. Otherwise the 
actual message data also prints. 
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bool 

PutData 

(Queue *pOutputOueue) 


bool 

PutData 

(HANDLE hOutPipe. 
ULQNG *pBvtesWritten) 


virtual void 
SetAddress 

(char *pAddress) 

virtual void 
SetDestination 


Allocates sufficient memory to hold a copy of 
the IfeMessageData structure associated with 
a message. The IfeMessageData is copied from 
the Class data area to the newly allocated 
memory. The pointer to the copied data is 
then placed on the specified queue. 

Returns FALSE if fails to create a new 
IFE Message object. 

Copies the contents of the IfeMessageData 
class variable to the pipe specified by 
hOutPipe. The number of bytes actually 
written to the pipe are returned in the 
pBvtesWritten argument. 

Returns FALSE if fails to output to the pipe. 

Updates the IfeMessageData Address data 
field with pAddress info. 


Updates the Destination field in the 
IfeMessageData data member. 


(IfeldType Destinationldl 

void Copies the IfeFunctionType input argument 

SetlfeFunction into the IfeFunction element of the 

IFE MESSAGE DATA structure associated 
(IfeFunctionType nlfeFunction) with this IFE Message. 


void Saves information about the host LRU. 

SetLruInfo 

(char *pLru!nfo) 

bool Fills the LRUType field in the IfeMessageData 

SetLruTuve structure for this IFE Message with the data 

contained in the input argument pszLruType. 
(char *pszLruType) Returns FALSE if input LruType is too big to 

store. 


Copies the specified data block to the 
MessageData field of this IFE Message object. 

(BYTE *pData, 

WORD wDataLen) 


void 

SetMessaaeData 
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void 

SetMessaaeLenath 


(long Length) 
void 

SetNetworkAddress 
(CString csNetworkAddressl 


virtual void 
SetSource 


Sets the MessageLength local data member to 
Length, 


Converts the Network Address in 
csNetworkAddress as necessary and writes 
the resulting data to the Raw Message Data 
buffer. The type of conversion required as 
well as the location of data in the Raw 
Message data buffer is determined by the 
identifier of the process that sent the message 
(i.e.. Message Source Id). 

Updates the Source field found in the 
IfeMessageData data member with Sourceld. 


(IfeldType Sourceld) 

void Sets the UnsolicitedMessage field for this 

SetUnsolicitedMessaae IFE Message object with the value contained 

in Message. 

(UnsolicitedMessageType Message) 


5 


The ARCNET Message class ARCNTMSS.CPP is a derived class from IFE Message. It is 
used to carry and process ARCNET data from the Message Processor to an appropriate 
Network Addressable Unit fe.g.. Seat NAU, Backbone NAU). It is used as a base class to 
any ARCNET devices, such as the Seat Message, PESCA Message, and PESCV Message 
classes. 


Some of the virtual functions defined in IFE Message have been overridden within 
ARCNET Message. 


ARCNET Message Class Public 
Functions 

ARCNET Messaae( 

IFE MESSAGE DATA 
*pIfeMessageData) 

ARCNET Messaael 
BYTE *pMessageData. 
CMapStringToPtr& LookUpTable) 


Purpose 


This constructor fills the IfeMessageData 
data member with the message data 
structure. 

This constructor takes what must be a 
valid message and parses it to fill the 
local structure. 
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ARCNET Message Class Public 
Functions 

bool 

BuildArcnetMessaael 
CMapStringToPtr& LookUpTable. 
char *pLRUName. 

BYTE *pOutBuf) 


Purpose 


This method builds the MessageData 
into an ARCNET message. The first two 
bytes of the output message buffer are 
set to the length of the message (as read 
from the MessageLength field of the 
IfeMessageData structure. The 
remainder of the output buffer is 
populated with the raw ARCNET data 
from the MessageData field of the 
IfeMessageData structure. 

Returns FALSE if failure. 


BYTE Returns the value of the Command Byte 

GetCommandf) in the ARCNET MessageData. 


IfeldType 

GetDestinationi 

CMapStringToPtr LookUpTable. 
char *pAddress) 


IfeFunctionType 
GetlfeFunctionl ) 

long 

GetMessaaeLenathi 
BYTE *pMessageData) 


bool 

IsTestPrimitive f 
BYTE bvTestPrimitive) 


bool 

PutDatai 

HANDLE hOutPipe. 
ULONG *pBvtesWritten) 


Extracts the Destination bytes from the 
ARCNET MessageData, attempts to map 
the raw data and returns the 
Enumerated IfeldType and Mapping 
address. 


Returns NoDestination if none found. 


Returns the IfeFunction data member. 


Processes the raw ARCNET data to 
determine the message length, update 
the local data member and return the 
value. 


Determines whether or not this 
IFE Message is a test primitive by 
comparing the command byte with the 
constant TP COMMAND. A value of 
TRUE is returned if the command byte 
equals TP COMMAND. 

A value of FALSE is returned otherwise. 


Overloaded ARCNET PutDatai) method. 
Completes the Message Header and calls 
the IFE Message function. 

Returns FALSE if write to OutPipe fails. 
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ARCUET Message Class Public 
Functions 

bool 

PutDatcA 

Queue *p0utput0ueue) 


bool 

SetAddressi 

CMapStrineToPtr LookUpTable. 
char *pAddressl 


void 

SetCommandf 
BYTE Command) 

void 

SetDestinatio n( 

IfeldType Destinationld) 

void 

SetPestinationi 

BYTE *pDestinationNetworkAddressl 
bool 

SetPestinationi 

CMapStringToPtr& LookUpTable. 
char *pAddressl 

void 

SetlfeFunctioni 
IfeFunctionTvpe Function) 

bool 

SetSource I 

CMapStrineToPtr LookUpTable. 
char *pAddressl 


void 

SetSource! 

BYTE *pSourceNetworkAddressl 


Purpose 


Overloaded ARCNET PutPataf) method. 
Completes the Messaee Header and calls 
the IFE Messaee function. 

Returns FALSe if no data was found to 
put into Queue. 

This method is an override of the 
IfeMessaee SetAddressf). It takes in a 
mappine table and an Address. The 
address is looked-up in the mappine 
table and if a match is found the 
Address data member is updated. 

Returns FALSE if unsuccessful. 

This method takes a Command Bvte and 
update the MessageData member. 


Simply calls the same IFE Message 
function to set the Destination data 
member. 

Parses the DestinationNetworkAddress 
for the IFE Message Destination. 


Looks up the pAddress in the specified 
LookUpTable to determine the 
corresponding Destination and stores it 
in the IFE Message Destination member. 
Returns FALSE if lookup fails. 

Updates the IFE Function with the given 
value. 


Cross-references the Address, fe.g., 'SDU 
OlA'l in the LookUpTable. If a match, 
updates the Source bvtes of 
MessageData with corresponding value. 

Returns FALSE if failure. 

This method takes the BYTE parameter 
and update the MessageData data 
member for source. 
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The following are virtual functions that may be used in classes derived from this class; 


ARCNET Message Class 
Virtual Functions 

Purpose 

virtual void 

To finish up the message for shipment. Base 

ComvleteMessaaeHeaderl) 

version simplv calls SetMessaaeLenathfL 

virtual void 

Base version simplv calls the IFE Message 

GetAddressl 
char *pAddress) 

version. 

virtual IfeldTvpe 

Base version simplv calls the IFE Message 

GetDestinationO 

version. 

virtual IfeldTvpe 

Base version simplv calls the IFE Message 

GetSource 0 

version. 

virtual void 

Base version simplv calls the IFE Message 

SetAddressl 

char *pAddress) 

version. 

virtual void 

Base version simplv calls the IFE Message 

SetDestinationl 
IfeldTvpe Destinationld) 

version. 

virtual void 

Handles ARCNET messages that do not have 

SetMessaoeLenathi) 

sub-functions (i.e., IF messages). Base version 


does nothing. 

virtual void 

Base version simplv calls the IFE Message 

SetSourcel 
IfeldTvpe Sourceldl 

version. 


ARCNET Simulation class ARCSMCLS.CPP contains similar functions to the runtime 
ARCNET Message class, except that instead of communicating with the actual ARCNET 
Driver, this simulates data I/O for test purposes, 

PESC-A Message class PSCMSSGE.CPP is derived from the ARCNET Message class to 
implement the functions needed to support the PESC-A devices. 

PESC-A Message Fumctiom Purpose 

bool Returns indication of whether landing gear is 
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PESC-A Message Function 
IsGearDownO 

bool 

IsGearComoressedn 


Purpose 

down and locked. 

Returns indication as to whether landing gear is 
compressed (weight on wheels). 


PESCV Message class PSCVMSSG.CPP is derived from the ARCNET Message class to 
implement the functions necessary to format and transmit interface messages between 
the Cabin Control Center and the PESC-V 224b. 


PBSC-V Message Function Purpose 


void Initializes the data portion of this 

WriteVideoControlData PESCV Message with all information necessary 

for a Video Control Message (0xE91. bvData 
(BYTE *bvDatal must contain the Video Control Data bvtes. 
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The Seat Message class SETMSSGE.CPP is derived from the ARCNET Message class to 
process Seat data between the Seat NAU and the Services. Methods and data relating 
to all seat sessioning and sales services! along with some cabin services, are provided. 


Seat Message Function 
void 

CompleteMessageHeaderi) 

BYTE 

GetAoDlicationldO 

double 

GetCashTotaU) 

BYTE 

GetCommandldO 

BYTE 

GetControlIdentifieri) 

void 

GetCreditCardAccountNumber 
(BYTE *pCreditCardAccountl 


Purpose 

Finishes up the message for shipment, adds 
message length, et. al. 

Retrieves the Application ID from the 
IFE Message data. 

Retrieves the Cash Total from the 
IFE Message data. 

Returns the Command ID found in the 
IFE Message data. 

Returns the Control Identifier found in the 
IFE Message data. 

Retrieves the Credit Card Data from the 
IFE Message data. 
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Seat Message Function Purpose 

void Retrieves the Credit Card Customer Name 

GetCreditCardCustomerName from the IFE Message data. 


(char *pCustomerName) 
void 

GetCreditCardExpirationDate 
(BYTE *pExpirationData) 
double 

GetCreditTotali) 

short 
GetFlaasi \ 

void 

GetFliahtAttendantld 
(char *pAttendant!dl 
BYTE 

GetMessaaeldO 

ID 

GetOrderldi) 

void 

GetProductCode 
(char *pProductCode) 
long 

GetProductMaoO 

BYTE 

GetOuantitul) 

BYTE 

GetRetruCounti ) 

void 
GetSeatl 
char *pSeatl 


Retrieves the Credit Card Expiration Date 
from the IFE Message data. 


Retrieves the Credit Total from IFE Message 
data and returns it as a floating point value. 

Retrieves the Flags from the IFE Message 
data. 


Retrieves the Flight Attendant Id from the 
IFE Message data. 


Returns the Message ID found in the 
IFE Message data. 

Returns the Order ID from the IFE Message 
data. 


Returns the Product Code from the 
IFE Message data. 


Returns the Product Map from the 
IFE Message data. 

Returns the Quantity from the IFE Message 
data. 


Returns the Retry Count from the 
IFE Message data. 

Returns the Seat from the IFE Message data. 
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Seat Message Function Purpose 

void Transfers the seat identifiers from the data 

GetSeatTransferData area of this IFE Message object into the two 

output arguments. 

(CString &csSeatl. 

CString &csSeat21 

WORD Returns the value of the Sequence Number 

GetSeauenceNumberO data member. 


BYTE Retrieves the session status from the 

GetSessionStatusO message 

BYTE Retrieves the Transaction Status from the 

GetTransactionStatusl) IFE message. 


BYTE 

GetUpdateTupel) 

void 

InitializeSeatl) 

void 

SetAddressf 
char *pAddressl 

void 

SetCashTotal 
(double Amount) 
void 

SetControUdentifier 


Retrieves the Update Type from the IFE 
message. 

Initializes the LengthMap array with seat Ids 
once per flight. 

Copies the Address info into the IFE Message 
data member. 


Copies the Amount into the IFE Message 
data. 


Copies the ID info into the IFE Message data. 


(BYTE ID! 

void Writes the value contained in bvFlags to the 

SetCPMSFlaas Flags location in the CPMS Status message. 

(BYTE bvFlagsl 

void Copies the CreditCardAccount data into the 

SetCreditCardAccountNumber IFE Message data. 


(BYTE *pCreditCardAccount) 
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Seat Message Function! 
void 

SetCreditCardCustomerName 


(char *pCustomerName) 
void 

SetCreditCardExvirationDate 
(BYTE *pExpirationDate) 
void 

SetCreditTotal 
(double Amount) 
void 

SetDBBuildldl 
WORD wBuildld) 

void 

SetElavsedTime 
(TIME tmElapsed) 
void 

SetHSDLOueueStatus 
(BYTE *pHSDLQueueStatus) 
void 

SetlfeStatel 
BYTE IfeState) 

void 

SetMessaaeld 
(BYTE Messageld) 
void 

SetMessaaeLenathl) 

void 

SetMessaaesProcessed 
(short MessagesProcessed) 


Purpose 

Copies the CustomerName data into the 
IFE Message data. 


Copies the ExpirationDate data into the 
IFE Message data. 


Formats as a dollar amount and copies 
Amount into the IFE Message data. 


Writes the value in wBuildld to the Database 
Build ID field position in the IFE Message 
data. 


Formats elapsed time 0 - 999 into 

IFE Message data. Values greater than 999 

are reduced to 999. 


Copies the High Speed Download Queue 
Status into the IFE Message data. 


Copies the IFE State value into the 
IFE Message data. 


Copies the Message Id into the IFE Message 
data. 


Sets the length of the IFE Message data 
based on the raw data message length. 

Copies the MessagesProcessed into the 
IFE Message data. 
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Seat Message Function 

void 

SetMovieCucleld 
(BYTE MovieCvcleld) 
void 

SetMoineCucleStatus 
(BYTE MovieCvcleStatus) 
void 

SetMovieNumber 
(BYTE MovieNumber) 
void 

SetNewVideoChannelNumber 


(BYTE ChannelNumber) 
void 

SetNewVideoRecordNumber 


(BYTE RecordNumber. 
BYTE Languageldl 

void 

SetOrderld 
(ID Orderld) 
void 

SetProductCode 
(char *pProductCode) 
void 

SetProductMav 
(long ProductMap) 
void 

SetOuantitu 
(BYTE Quantity) 


Purpose 

Copies the MovieCvcleld into the 
IFE Message data. 


Copies the MovieCvcleStatus into the 
IFE Message data. 


Copies the MovieNumber into the 
IFE Message data. 


Copies the ChannelNumber into the 
IFE Message data. 


Copies the RecordNumber into the 

IFE Message data using Languageld to pad 

the text field appropriately. 


Copies the Orderld into the IFE Message 
data. 


Copies the ProductCode into the 
IFE Message data. 


Copies the ProductMap into the IFE Message 
data. 


Copies the Quantity into the IFE Message 
data. 
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Seat Message Function 

void 

SetOueuePosition 
(short QueuePositionl 
void 

SetSeatTransferData 

(CString &csSeatl, 

CString &csSeat2) 

void 

SetSEBMessaainaOffl) 

void 

SetSEBMessaainaOnl) 

void 

SetSEBMessaaeSeatAddress 


(char *SeatAddress) 
void 

SetSeauenceNumber 
(WORD SequenceNumber) 
void 

SetSessionStatus 
(BYTE SessionStatus) 
void 

SetSIBackliahtCmd 
(bool bBacklightOn) 
void 

SetStoreStatus 
(BYTE *StoreStatus) 
void 

SetTimeLeftOnCurrentCiicle 


Purpose 

Copies the OueuePosition into the 
IFE Message data. 


Copies the seats identified by the two input 
arguments into the IFE Message data. 


Sets IFE Message data to SEB-Messaging 
Off. 

Sets IFE Message data to SEB-Messaging 
On. 


Copies SeatAddress into the IFE Message 
data. 


Copies SequenceNumber into the 
IFE Message data. 


Copies the SessionStatus into the 
IFE Message data. 


Sets the Message ID to SI BACKLIGHT CTL 
and the first data byte 1 (ON) or 0 (OFF) 
based on bBacklightOn. 


Copies StoreStatus into the IFE Message 
data. 


Copies tmRemaining into the IFE Message 
data. 


(TIME tmRemaining) 
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Seat Message Function, 
void 

SetTimeUntilNextShowina 
(TIME tmNextShow) 
void 

SetTransactionStatus 
(BYTE TransactionStatus) 
void 

SetUpdateTuve 
(BYTE UpdateType) 


Purpose 

Copies tmNextShow into the IFE Message 
data. 


Copies TransactionStatus into the 
IFE Message data. 


Copies UpdateType into the IFE Message 
data. 


The TestPort Message class TSTPRTMS.CPP is derived from ARCNET Message to 
communicate with the test port of the file server. 


TestPort Message Class Function 
void 

GetBiteResults 

(DWORD *pdwErrorCode, 

DWORD *pdwTestID. 

DWORD *pdwWitnessType, 

DWORD *pdwSuspectType. 
DWORD *pdwSuspectID, 

DWORD *pdwTSData. 

DWORD *pdwErrorClear) 

void 

GetRawSourceAddress 
(BYTE *pszSrcAddrs) 

BYTE 

GetSubCommandl) 


Purpose 

Extracts data from an BIT BITE STATUS 
(op status) and returns it to the calling 
function for inclusion in the Application 
event log. 


Extracts the source address field from the 
IFE Message data and copies it into 
pszSrcAddrs. 


Returns the Subcommand byte from the 
IFE Message data. 


bool 

SetRevInfo 
(BYTE *pbvRevInfo) 


Parses the text contained in the 
pszRevInfo string and formats the data 
into the IFE Message data. 
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void Sets the Subcommand byte in the 

SetSubCommand IFE Message data with command. 


(BYTE command) 


5 


StandardProtocol class STNDRDPR.CPP is derived from the IFE Message class and is 
the base class that supports the Hughes standard start-stov protocol as described in 
the, which is used in communications with PATMessage class, PIMessage class, 
PATSEBMessage class. 


StamdardlRgotocol Class Functions 
bool 

Decodel) 

void 

Encoded 

BYTE 

GetCommandl) 

bool GetData 

(HANDLE hlnPipe, 

ULQNG *pBvtesRead) 

bool 

GetData 

(Queue *p!nputOueue) 

BYTE 

GetLenathOfCommand(\ 


Purpose 

Decode data from Hughes standard 
start-stop data into just plain data. 
Returns FALSE if decoding failed. 

Encodes the data into the Hughes 
standard start- stop format. 

Returns the Command Byte from the 
IFE Message data. 

Reads data from the hlnPipe into the 
IFE Message data. Returns the number 
of bytes read in pBvtesRead. 

Returns FALSE if read failed. 

Reads and encodes the data from the 
InputOueue into the IFE Message data. 
Returns FALSE if no data or if pointer is 
NULL. 

Returns the Command Length from 
IFE Message data. 


bool 

Is ValidCommandO 


Returns FALSE if Command in 

IFE Message is not recognized as one of 

the Standard Protocol commands. 


bool 

PutData 

(HANDLE hOutPipe, 
ULQNG *pBvtesWrittenl 


Outputs encoded data from IFE Message 
data to the OutPipe, reporting the 
number of BvtesWritten. 

Returns FALSE if failed the written. 
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StandardProtocol Class Functions Purpose 


bool 

PutData 

(Queue *pOutputOueue) 


Decodes the data from the IFE Message 
data and puts it on the OutputOueue. 
Returns FALSE if message could not be 
decoded. 


void 

SetLenathi) 


Sets the Message Length and 
Destination Address of the IFE Message. 


The PATMessage PATMSSGE.CPP is derived from StandardProtocol to support 
communication with the primary access terminal's 225 PI board. 


PATMessage Function 


Purpose 


void 

ConvertCardPataToASCIIFormat 


(unsigned char *pCardData, 
long ICardDataLength) 

void 

ConvertPrinterStatusToASCII 


(long IPrinterStatus) 
void 

DerivedDecodei) 

void 

PerivedEncodel) 

void 

GetAudioChannel 

fBYTE *LeftTimeSlot. 
BYTE *RightTimeSlot) 


GetCardPataBinaruFormat 
(unsigned char *pCardData) 


Converts binary format card data in 
pCardData to ASCII format in 
IFE Message data. Requires 
CardDataLength to set the length of the 
IFE Message data field. 

Converts PrinterStatus to ASCII format 
and stores in IFE message data. 


Stub. 


Stub. 


Stub. 


Copies magcard data (MagCardReadData 
Command is first byte) in the original 
binary format into pCardData. Size of 
user-supplied buffer should be 
MAXMESSAGEDATASIZE. Returns 
adjusted message length. 

Returns 0 if unable to copy data. 
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PATMessage Function 
BYTE 

GetControlButel) 

BYTE 

GetPestinationPeviceO 

BYTE 

GetSourceDevicel) 

void 

GetVideoPreinewChannel 

(BYTE ^Channel. 

BYTE *AudioSell 

void 

GetVideoPreviewSource 

(char * Source) 

void 

SetAddress 
(char * Address) 
void 

SetAudioChannel 

(BYTE LeftTimeSlot. 

BYTE RightTimeSlot) 

void 

SetAudio Volume 

(BYTE LeftVolume, 

BYTE RightVolume) 

void 

SetCardDatal 

unsigned char *pCardPata) 
void 

SetDestinationDevice 
(BYTE bvPstPeviceAddr) 


Purpose 

Returns the control byte from the 
IFE Message data. 

Returns address of destination device 
from IFE Message data. 

Returns address of source device from 
IFE Message data. 

Returns the Preview Channel info from 
the IFE, Message data into Channel and 
AudioSel. 


Stub, 


Simply calls the IFE Message version. 


Pevelops the Audio Channel info in the 
IFE Message data based on the 
LeftTimeSlot and RightTimeSlot values. 


Pevelops the Audio Volume info in the 
IFE Message data based on the 
LeftVolume and RightVolume values. 


Sets up request to PI to dump the most 
recent magcard buffer into CardPata. 


Sets address of destination device in 
IFE Message data to bvPstPeviceAddr. 
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PATMessage Function 


Purpose 


void 

SetSourceDevice 

(BYTE bvSrcDeviceAddr) 

void 

SetVideoPreviewChannel 


(BYTE Channel. 

BYTE AudioSel) 

void 

SetVideoPreviewSource 


Set address of source device in 

IFE Message data to bvSrcDeviceAddr. 


Copies the Channel and AudioSel data 
into IFE Message data. 


Stub. 


fhar *Source) 


The PIMessaee class PIMSSAGE.CPP is derived from the StandardProtocol class to 
handle the specifics of the primary access terminal's 225 PI board. 


PIMessage Class Function 

void 

DerivedDecodeO 

void 

DerivedEncodel) 

BYTE 

fooGetCommandi) 

BYTE 

fooGetLenathOfCommandl) 

bool 

fools ValidCommandl \ 
bool 

GetCardData 

(unsigned char *CardDatal 


Purpose 

Massages the data in IFE Message data for 
local usage. 

Massages the data in IFE Message data for 
output to the PI board. 

For testing only. 


For testing only. 


For testing only. 


Stub. Always returns FALSE. See 
PATMessage for this functionality. 
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PflMessage Class Function* 

Purpose 

bool 

GetCurrentChannelResvonse 

(BYTE ‘Channel. 

BYTE ‘AudioSell 

If the current command was a Channel 
Reauest, this returns the Channel and 
AudioSel. 

Otherwise returns FALSE. 

BYTE 

GetMsaCommandButel) 

Returns the Command Bvte from last 
PIMessage. 

bool 

GetPartAndRevisionData 

If current command was a Part&Revision 
command, conies the data from IFE Message 

(BYTE ‘PartAndRevisionl 

data into PartAndRevision. 
Otherwise returns FALSE. 

bool 

If current command was a Status Reauest 

GetStatusResponse 

command, conies the data from IFE Message 

(BYTE ‘Response) 

data into Response. 
Otherwise returns FALSE. 

bool 

If current command was a Video Preview VCP 

GetVideoPreviewVCP 

command, returns the current VCP assigned 

(char *VCPName) 

to Video Preview screen, persisted bv 
Pllnterface VLRU into VCPName. 
Otherwise returns FALSE. 

bool 

Returns TRUE only if the current Command is 

IsCardReaderCommandO 

one from the card reader. 

bool 

Returns TRUE only if the current Command is 

IslltnerCommandl) 

one from or for the Tuner. 

bool 

IsUnsolicatedl) 

Stub. Always returns FALSE. 

void 

PartAndRevisionReauesti ) 

Builds a Part&Revision Reauest into the 
IFE Message data. 

void 

Stub. See PATMessage for this functionality. 

PutCardData 


(unsigned char *CardData) 


void 

Builds a Current Channel Reauest into the 

ReauestCurreritChanneU) 

IFE Message data. 

void 

Builds an Ack-bv-Current-Command into the 

SetAckl 

BYTE bvCmdToBeAcked) 

IFE Message data. 


98-PS-039 





-432- 


PlMessage Class Function 
void 

SetMsaCommandByte 

fBYTE bvMsgCmd) 

void 

SetNak 

(BYTE bvCmdToBeNaked) 
void 

SetVideoPreviewTo VCP{ 
char *VCPName) 

void 

SoftwareReseti) 

void 

StatusReguestl) 

void 

SwitchTunerTuve 
(BYTE TuneiType) 
void 

TuneChannel 

(BYTE Channel. 

BYTE AudioSel) 


Purpose 

Copies bvMsgCmd into the Message 
Command Byte class member data. 


Builds a NAK-bv-Current-Command into the 
IFE Message data. 


Stub, 


Builds a Software Reset Command into the 
IFE Message data. 

Builds a Status Request Command into the 
IFE Message data. 

Builds a Switch Tuner Type Command into 
the IFE Message data. 


Builds a Tune Channel Command into the 
IFE Message data using Channel and 
AudioSel as part of the command. 


The PATSEBMessage class PTSBMSSG.CPP is derived from StandardProtocol but 
currently none of its functions are implemented. Therefore, it behaves exactly like 
StandardProtocol. 

PATSEBMessage Class Function Purpose 

void DerivedDecodel) Stub, 

void DerivedEncode 0 Stub. 

BYTE GetLenathOfCommandl) Stub. Returns Zero. 
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PATSEBMessage Class Function Purpose 

bool IsValidCommancLW If Command is recognized by 

GetLenathOfCommandfL returns TRUE. 
Currently returns FALSE. 


The Serial Message SRLMSSGE.CPP is derived from IFE Message. It is used to carry 
and process Serial data from the Message Processor to anv serial I/O devices NAU. 
Currently, it is the base class for VCP Message. The pure virtual functions defined in 
IFE Message is implemented within Serial Message. 


Serial Message Function Purpose 

bool Local version reads data into IFE Message data 

GetData from InPipe. returning the number of BvtesRead. 

Returns FALSE if no data read from InPipe. 

(HANDLE hlnPipe. 

ULONG *nBvtesReadl 

bool 
GetData 


(IfeldTvpe idSource. 

IfeldType idDestination. 

BYTE *pData, 

DWORD dwDataLenl 

bool Simply calls the IFE Message version. 

GetData 


Local version fills IFE Message data structures with 
data contained in input arguments. 

Always returns TRUE. 


(Queue *p!nputOueue) 

bool Local version copies the data and length elements 

PutData from an IFE Message to the specified arguments. 

Always returns TRUE. 

(BYTE *bvData. 

DWORD *pDataLenl 

bool Simply calls the IFE Message version. 

PutData 


(HANDLE hOutPioe. 

ULONG *pBvtesWrittenl 

bool Simply calls the IFE Message version. 

PutData(Oueue 

*pQutputOueuel 
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The VCP Message class VCPMSSGE.CPP is derived from Serial Message (which is 
derived from IFE Message) to communicate with the Video Players. It is used between 
the Message Processor and the VCP NAU. 


VCP Message Class Function 

void 

Format 

(VCPMessageFormat nMessageFormat) 

CString 

GetAddressO 


void 

GetCommancLData 

(PLAYERCOMMANDS 
*pPlaverCommand, 
BYTE *bvData. 
int *pDataLen) 

CString 

GetLruInfol) 


void 

GetPlauerResponse 

(PlaverCommands *pPlaverCommand. 
PLAYERSTATE *pPlaver State. 

BYTE *pData, 

BYTE *pDataLen) 

void 

GetResponseData 

IfeFunctionType *pResponseCommand. 
BYTE *bvData. 
int *pDataLen) 

PLAYERSTATE 

GetStatel) 


Purpose 

Stub. 

t 


Overrides the one in the IFE Message 
base class. 

Returns the contents of the 

IFE Message data Address field in a 

CString. 

If a valid VCP PlaverCommand, parses 
out the Command Bytes from the 
IFE Message data, returning it in 
bvData. 

Returns the number of bytes in 
DataLen, Zero if invalid command. 


Overrides the one in the IFE Message 
class. This version creates a CString 
from the data contained in the Lrulnfo 
field of the IfeMessageData structure 
and returns it to the function. 

Stub 


Parses data from IFE Message data into 
bvData, returning the DataLen size of 
the data. Returns responses Ack or 
Nak in ResponseCommand. 


Returns the enumerated state of the 
VCP le. g.. Playing, FastForward. etc.) 
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VCP_Message Class Function 

void 

GetStatelnfo 

(PLAYERSTATE *pState. 
DWORD *pTimel 

bool 

Is ValidChecksuml) 
void 

SetAddress 
(CString cs Address) 


void 

SetChecksuml) 


void 

SetLruInfol 
CString csLralnfo) 

void 

SetPlauerCommand 

(PlaverCommands nPlaverCommand, 
BYTE *bvData. 

BYTE bvDataLen) 

void 

SetStatelnfo 

(PLAYERSTATE nState, 

DWORD dwTimel 

void 

SetUnitld 

(PGENERIC TEXT pszUnitld) 


Purpose 

Retrieves state information from this 
IFE Message object. Assumes that 
state information was writing using the 
SetStatelnfo member function. 


Returns FALSE if checksum test. 


Overrides SetAddress in IFE Message 
base class. Address field of the 
IfeMessageData structure for this 
message is populated using the CString 
input argument. 

Calculates and writes a checksum to 
the IFE Message. Then stores the full 
length of the message in the 
MessageLength field of the message. 

Overrides the function in the 
IFE Message base class. This version 
copies the csLruInfo data to the Lrulnfo 
field of IFE Message data. 

Converts enumerated internal 
PlaverCommand into the actual 
command byte to go to the VCP. 

Returns any associated data from 
IFE Message data into bvData and 
returns its length in DataLen. 

Writes VCP State and Time information 
to the IFE Message data. State 
information is retrieved using 
GetStatelnfofl 


Writes the Unitld into the IFE Message 
data. 


Thus, systems, methods and articles of manufacture have been disclosed that provide 
for a networked passenger entertainment system that integrates audio, video, passenger 
information, product ordering and service processing, communications, and 
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maintainability features, and permits passengers to selectively order or request 
products and services, receive video, audio and game data for entertainment purposes, 
and communicate with other passengers and computers on- and off-board the aircraft, 
and which thereby provides for passenger selected delivery of content over a 
communication network. It is to be understood that the above-described embodiments 
are merely illustrative of some of the many specific embodiments that represent 
applications of the principles of the present invention. Clearly, numerous and other 
arrangements can be readily devised by those skilled in the art without departing from 
the scope of the invention. 
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A computer system server is used to manage communication over a network 
between on e or more network addressabl e unit s the system server and a 
plurality of physical devices of a passenger entertainment system. The 
system is configured and operated using software to provide passenger 
entertainment s ervice s including audio and video on - demand, information 
di ss emination, product and se rvice ord e r proces s ing, video teleconf e r e ncing 
a nd data - eommunication servi ces ^ The system inelude s- a -s y s tem s erver and 
a n e twork supporting multipl e comput e r proce s sors. Th e proce s sors and th e 
s erver comprise application s oftware that control t e l e phony application s and 
n e twork se rvice s . The serv e r i s coupled by way of the network to phy s ical 
d e vic es of the sy s t e m. The server comprises software for instantiating a 
dispatch object to open a framework network addressable unit objects, for 
instantiating one or more virtual line replaceable unit objects to manage 
communication between a network address unit and physical devices, and 
for communicating network messages through the dispatch object to network 
addr e ssabl e unit obj e cts to the physical devices. The dispatch object 
contain s logic that tracks messages to the physical devices utilizing a queue T 

logic that and tracks messages from the physical devices utilizing a queue T » 

and logic that convert s- me ss age s from a - fir s t format to a se cond forma t^ The I 

dispatch object maintains the status of related devices. The dispatch object 

also contain s logic for addin g adds and r e movin gremoves one or more of the 

network ^ addre ss abl e unit obi e et s . virtual line replaceable units. The network 

addressable unit objects include logic for - movin g move data from one storage 

location to another. 
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